EU AI Act

Under the EU AI Act, a provider develops an AI system or places it on the market under its own name; a deployer uses an AI system under its authority in a professional context. The roles carry very different obligations: providers bear the heavy technical duties (Art. 9-15, 19, 43, 48, 49, 72), while deployers bear a lighter operational set (Art. 26, 27). The same organization can be both at once, and determining your role per system is the first compliance step.

The OECD AI Principles are the first intergovernmental standard on AI, adopted in May 2019 and updated in May 2024, with 47 adhering jurisdictions including the European Union. They consist of five values-based principles for AI actors and five recommendations for policymakers. They are not law, not certifiable, and not a management system: they are the shared reference point that the EU AI Act, national AI strategies, and international frameworks build on. The OECD classification framework for AI systems, published in 2022, is the practical instrument that operationalizes them.

Art. 26.1 requires deployers to use high-risk AI systems strictly in accordance with the provider's instructions for use. This means using the system only for its intended purpose, within its specified technical configuration, and by qualified users, and documenting that compliance. Deviating from the instructions can shift liability entirely to the deployer.

Art. 26.2 requires deployers to ensure that the people assigned to oversee a high-risk AI system have the competence, training, and authority to do so effectively. Valid oversight is substantive, not formal: the overseer must understand the system, be trained on its limitations, and hold genuine authority to override its outputs.

Art. 4 has required organizations since 2 February 2025 to ensure a sufficient level of AI literacy among staff who operate or use AI systems, proportionate to the system and the role. It applies to all AI use, not only high-risk systems, and must be demonstrable.

The EU AI Act phases in between 2025 and 2028: the Art. 5 prohibitions and Art. 4 AI literacy applied from 2 February 2025, the Art. 50 transparency obligations from 2 August 2026, and the full high-risk obligations for Annex III systems from 2 December 2027 following the Omnibus amendments.

AI certification is not one category. Three different objects are assessed, each by a different kind of assessor: a person, an organization's AI management system, and an AI system placed on the EU market. The first two can be certified. The third is subject to a legal conformity assessment, which produces a certificate on one of its two routes and none on the other. Identifying which object a credential covers is the first step to judging what it is worth.

AI recruitment systems fall under Annex III of the EU AI Act as high-risk, which triggers the full deployer obligations of Article 26, human oversight, data quality, monitoring, log retention, and a Fundamental Rights Impact Assessment under Article 27. These duties cannot be transferred to the software vendor.

For SMEs, EU AI Act compliance is manageable but not optional: the Art. 5 prohibitions and Art. 4 literacy apply regardless of size, and SME deployers of high-risk AI carry the full Art. 26 obligations in proportionate form. Micro-enterprises gain administrative simplifications, not exemptions.

The AI Officer is the organization-wide director of responsible AI use, broader than a compliance role: it covers AI strategy, ethics, risk and literacy. The EU AI Act (Art. 26) makes the coordinating function necessary, but the need for an AI Officer extends beyond the law itself.

EU AI Act obligations per department depend on the risk class of the AI system. HR selection and credit scoring are high-risk (Annex III) and carry the full Art. 26 obligations; marketing AI and chatbots usually fall under the transparency obligation of Art. 50. A per-system Art. 6 analysis determines the exact obligation.

The first steps to EU AI Act compliance for deployers are: build an AI inventory, classify each system against Art. 6, request the provider documentation, start AI-literacy training under Art. 4, and assign ownership. These steps create the foundation for the Art. 26 obligations.

Micro-enterprises (fewer than 10 employees and turnover up to €2 million) can use a simplified compliance pathway under the EU AI Act, mainly for the provider role: simplified technical documentation (Art. 11.3) and a proportionate quality management system (Art. 17.3). The material obligations, the Art. 5 prohibitions, human oversight, and incident reporting, still apply in full.

An AI policy is the governance instrument that translates the EU AI Act's obligations into organizational commitments and accountabilities. An EU AI Act-aligned policy covers at least the scope, AI principles, the governance structure, the AI inventory and classification, the Art. 5 prohibitions, the approval process, human oversight, literacy, and incident reporting.

Art. 5 lists the eight prohibited AI practices, including subliminal manipulation, exploitation of vulnerable groups, social scoring, and untargeted facial-recognition scraping. These prohibitions are absolute, apply to every organization regardless of size, and have been in force since 2 February 2025.

The EU AI Act phases in between 2025 and 2028: the Art. 5 prohibitions and Art. 4 AI literacy applied from 2 February 2025, the Art. 50 transparency obligations from 2 August 2026, and the full high-risk obligations for Annex III systems from 2 December 2027 following the Omnibus amendments.

For SMEs, EU AI Act compliance is manageable but not optional: the Art. 5 prohibitions and Art. 4 literacy apply regardless of size, and SME deployers of high-risk AI carry the full Art. 26 obligations in proportionate form. Micro-enterprises gain administrative simplifications, not exemptions.

EU AI Act obligations per department depend on the risk class of the AI system. HR selection and credit scoring are high-risk (Annex III) and carry the full Art. 26 obligations; marketing AI and chatbots usually fall under the transparency obligation of Art. 50. A per-system Art. 6 analysis determines the exact obligation.

Whether an AI system is high-risk depends on Art. 6: it is high-risk if it is a safety component under Annex I or falls within an Annex III use case (such as employment, credit, or essential services). The Art. 6.3 exception can apply where the system performs only a narrow, non-decisive task.

Micro-enterprises (fewer than 10 employees and turnover up to €2 million) can use a simplified compliance pathway under the EU AI Act, mainly for the provider role: simplified technical documentation (Art. 11.3) and a proportionate quality management system (Art. 17.3). The material obligations, the Art. 5 prohibitions, human oversight, and incident reporting, still apply in full.

An AI policy is the governance instrument that translates the EU AI Act's obligations into organizational commitments and accountabilities. An EU AI Act-aligned policy covers at least the scope, AI principles, the governance structure, the AI inventory and classification, the Art. 5 prohibitions, the approval process, human oversight, literacy, and incident reporting.

Art. 6 sets out how to classify a high-risk AI system: a system is high-risk if it is a safety component of a product under Annex I, or falls within one of the Annex III use cases. Misclassification is itself a violation, and the responsibility rests with the organization, not the supplier.

Under the EU AI Act, splitting an autonomous workflow across several agents does not split its regulatory classification. The Commission's draft guidelines on high-risk classification, published in May 2026, state that a complex system made up of several AI components, including an agentic stack of orchestrators and sub-agents, is assessed as a whole. An orchestrator coordinating sub-agents toward a high-risk decision is one high-risk system, and the full weight of the Act's high-risk obligations attaches to the stack, not to its parts.

EU AI Act obligations per department depend on the risk class of the AI system. HR selection and credit scoring are high-risk (Annex III) and carry the full Art. 26 obligations; marketing AI and chatbots usually fall under the transparency obligation of Art. 50. A per-system Art. 6 analysis determines the exact obligation.

The first steps to EU AI Act compliance for deployers are: build an AI inventory, classify each system against Art. 6, request the provider documentation, start AI-literacy training under Art. 4, and assign ownership. These steps create the foundation for the Art. 26 obligations.

Whether an AI system is high-risk depends on Art. 6: it is high-risk if it is a safety component under Annex I or falls within an Annex III use case (such as employment, credit, or essential services). The Art. 6.3 exception can apply where the system performs only a narrow, non-decisive task.

Art. 10 requires that the training, validation, and testing data for high-risk AI systems meets quality criteria: relevant, sufficiently representative, and as free of errors and complete as possible for the intended purpose. It also requires documented data governance practices covering collection, preparation, bias examination, and gap mitigation, and it permits the limited processing of special-category data where strictly necessary to detect and correct bias, under safeguards.

Art. 9 requires providers of high-risk AI systems to establish, document, and maintain a risk management system that runs across the entire lifecycle. It is a continuous, iterative process: identify the known and foreseeable risks, estimate and evaluate them, and adopt targeted mitigation measures, updating the cycle as the system and its environment change. It is not a one-time pre-deployment assessment.

Assessing the risk of an AI agent does not need a separate method. The steps stay the same: recognize the risk, assess how likely and how severe it is for your system, and control it. What changes is the input. An agent runs the process through recorded architecture decisions, about the model, the instruction, retrieved knowledge, tools, orchestration, memory, and autonomy, and each of those decisions, alone or in combination, creates the possibility of harm. The output of the assessment is a set of risk scenarios with a control objective for each.

AI governance is not a parallel structure that sits beside enterprise risk management. It belongs inside it. The seven pillars of responsible AI are the control structure the organization uses to govern each AI system; enterprise risk management is the machine that carries the residual risk those controls leave behind into the board's risk appetite, the risk register, and the assurance plan. The practical question is not whether to build AI governance or ERM, but how to slot the first into the second so that one accountable structure, not two competing ones, owns AI risk.

Control-level compliance means satisfying the EU AI Act through engineered, evidenced controls rather than policy documents. The technical articles translate directly into system controls: automatic, retained logs (Art. 12, 19), a stop function to a safe state (Art. 14(4)(e)), input masking before the model as a GDPR and Art. 26(4) control, configurable block policies (Art. 26), risk scoring and incident reporting within deadline (Art. 9, 73), and workspace isolation with role-based access (Art. 14, 26). Compliance at this level is an instrumented system, not a policy as PDF.

The NIST AI Risk Management Framework is a voluntary framework for identifying, assessing, and treating AI risk, published by the US National Institute of Standards and Technology in January 2023. It organizes the work in four functions: govern, map, measure, and manage. It is a method, not a legal requirement and not a certifiable standard: no organization can be certified against it, and following it creates no presumption of conformity with the EU AI Act. Its value is the risk vocabulary and process it supplies inside a management system.

Under the EU AI Act, splitting an autonomous workflow across several agents does not split its regulatory classification. The Commission's draft guidelines on high-risk classification, published in May 2026, state that a complex system made up of several AI components, including an agentic stack of orchestrators and sub-agents, is assessed as a whole. An orchestrator coordinating sub-agents toward a high-risk decision is one high-risk system, and the full weight of the Act's high-risk obligations attaches to the stack, not to its parts.

AI risk management is the practice of knowing which risks your AI systems carry and keeping them within bounds you chose deliberately. The risks are not abstract: each of the seven pillars of responsible AI has concrete ways it fails in practice, from a model that quietly disadvantages one group to a system whose accuracy decays after deployment. Managing them follows one repeatable pattern: recognize the risk, assess how likely and how serious it is for your system, and control it with measures you can test.

An SME that develops an AI system and makes it available to others is a provider under the EU AI Act and carries a substantially heavier burden than a deployer: for high-risk AI this includes a risk management system (Art. 9), data governance (Art. 10), technical documentation (Annex IV), conformity assessment (Art. 43), CE marking (Art. 48), and EU database registration (Art. 49).

AI governance is the system through which an organization makes responsible use of its AI and can prove it. It is not an ethics statement or a one-time project but an operating discipline that runs for the full life of every AI system the organization builds, buys, or embeds, carrying each responsible-AI principle down a chain from the harm that would breach it, through the risk and the control that reduces it, to the evidence that the control works.

Art. 10 requires that the training, validation, and testing data for high-risk AI systems meets quality criteria: relevant, sufficiently representative, and as free of errors and complete as possible for the intended purpose. It also requires documented data governance practices covering collection, preparation, bias examination, and gap mitigation, and it permits the limited processing of special-category data where strictly necessary to detect and correct bias, under safeguards.

Art. 9 requires providers of high-risk AI systems to establish, document, and maintain a risk management system that runs across the entire lifecycle. It is a continuous, iterative process: identify the known and foreseeable risks, estimate and evaluate them, and adopt targeted mitigation measures, updating the cycle as the system and its environment change. It is not a one-time pre-deployment assessment.

Control-level compliance means satisfying the EU AI Act through engineered, evidenced controls rather than policy documents. The technical articles translate directly into system controls: automatic, retained logs (Art. 12, 19), a stop function to a safe state (Art. 14(4)(e)), input masking before the model as a GDPR and Art. 26(4) control, configurable block policies (Art. 26), risk scoring and incident reporting within deadline (Art. 9, 73), and workspace isolation with role-based access (Art. 14, 26). Compliance at this level is an instrumented system, not a policy as PDF.

An SME that develops an AI system and makes it available to others is a provider under the EU AI Act and carries a substantially heavier burden than a deployer: for high-risk AI this includes a risk management system (Art. 9), data governance (Art. 10), technical documentation (Annex IV), conformity assessment (Art. 43), CE marking (Art. 48), and EU database registration (Art. 49).

Most organizations can describe their AI agents in detail: the architecture, the tools, the memory, the base model, the benchmarks, the internal safety testing. What far fewer can do is govern what those agents decide once they are running. Documentation answers the question "what is this agent and what can it do?" Governance answers a harder one: "can we trust the decisions it makes over time?" The two are routinely confused, and an agent that is thoroughly documented but ungoverned is exactly the kind of system that passes every review and then fails in production.

Under the EU AI Act, splitting an autonomous workflow across several agents does not split its regulatory classification. The Commission's draft guidelines on high-risk classification, published in May 2026, state that a complex system made up of several AI components, including an agentic stack of orchestrators and sub-agents, is assessed as a whole. An orchestrator coordinating sub-agents toward a high-risk decision is one high-risk system, and the full weight of the Act's high-risk obligations attaches to the stack, not to its parts.

Micro-enterprises (fewer than 10 employees and turnover up to €2 million) can use a simplified compliance pathway under the EU AI Act, mainly for the provider role: simplified technical documentation (Art. 11.3) and a proportionate quality management system (Art. 17.3). The material obligations, the Art. 5 prohibitions, human oversight, and incident reporting, still apply in full.

Art. 12 requires high-risk AI systems to technically allow for the automatic recording of events (logs) over their lifetime. The logging must enable traceability of the system's functioning at a level appropriate to its intended purpose, support post-market monitoring, and help identify situations that may lead to risk or substantial modification. It is a design obligation on the provider that makes the system auditable by construction.

Art. 19 requires providers of high-risk AI systems to keep the logs that the system automatically generates (under Art. 12) for as long as they control them, for a period appropriate to the intended purpose and at least six months unless other law requires longer. It is the retention counterpart to the Art. 12 logging capability, and it works alongside the deployer retention duty in Art. 26.6.

Control-level compliance means satisfying the EU AI Act through engineered, evidenced controls rather than policy documents. The technical articles translate directly into system controls: automatic, retained logs (Art. 12, 19), a stop function to a safe state (Art. 14(4)(e)), input masking before the model as a GDPR and Art. 26(4) control, configurable block policies (Art. 26), risk scoring and incident reporting within deadline (Art. 9, 73), and workspace isolation with role-based access (Art. 14, 26). Compliance at this level is an instrumented system, not a policy as PDF.

Most organizations can describe their AI agents in detail: the architecture, the tools, the memory, the base model, the benchmarks, the internal safety testing. What far fewer can do is govern what those agents decide once they are running. Documentation answers the question "what is this agent and what can it do?" Governance answers a harder one: "can we trust the decisions it makes over time?" The two are routinely confused, and an agent that is thoroughly documented but ungoverned is exactly the kind of system that passes every review and then fails in production.

An audit trail for EU AI Act compliance is the structured, retained record, combining the system logs (Art. 12) with the deployer's own oversight and monitoring documentation, that lets you demonstrate to a supervisor that a high-risk AI system was used lawfully.

Art. 14 requires providers to design and build high-risk AI systems so that they can be effectively overseen by humans during use. The system must let an overseer understand its capabilities and limits, watch for anomalies, resist automation bias, correctly interpret outputs, decide not to use the system, and intervene or stop it through a kill switch (Art. 14(4)(e)). It is the design obligation that makes the deployer oversight duty of Art. 26.2 possible.

Art. 26.1 requires deployers to use high-risk AI systems strictly in accordance with the provider's instructions for use. This means using the system only for its intended purpose, within its specified technical configuration, and by qualified users, and documenting that compliance. Deviating from the instructions can shift liability entirely to the deployer.

A supplier checklist for AI procurement verifies what a provider must deliver before you can comply as a deployer: the instructions for use (Art. 13.3), the conformity declaration, the risk classification, update notification, and cooperation in a supervisory investigation.

Art. 14 requires providers to design and build high-risk AI systems so that they can be effectively overseen by humans during use. The system must let an overseer understand its capabilities and limits, watch for anomalies, resist automation bias, correctly interpret outputs, decide not to use the system, and intervene or stop it through a kill switch (Art. 14(4)(e)). It is the design obligation that makes the deployer oversight duty of Art. 26.2 possible.

Art. 26.2 requires deployers to ensure that the people assigned to oversee a high-risk AI system have the competence, training, and authority to do so effectively. Valid oversight is substantive, not formal: the overseer must understand the system, be trained on its limitations, and hold genuine authority to override its outputs.

Agentic AI does not need a new kind of governance. Autonomy widens the gap between what a system does and who is accountable for it, which makes the existing governance chain, control tracing to risk and forward to evidence, more important, not less. The actions are real and sometimes irreversible, so the stakes on each control rise.

Agentic AI is AI that carries out a chain of actions on its own rather than producing a single output for a human to review. That shift does not add a new responsible-AI principle; it changes how every existing principle has to be governed. The human checkpoint moves from inside each decision to around the whole system: setting the bounds the agent operates within, monitoring the chain as it runs, and holding the ability to intervene.

Control-level compliance means satisfying the EU AI Act through engineered, evidenced controls rather than policy documents. The technical articles translate directly into system controls: automatic, retained logs (Art. 12, 19), a stop function to a safe state (Art. 14(4)(e)), input masking before the model as a GDPR and Art. 26(4) control, configurable block policies (Art. 26), risk scoring and incident reporting within deadline (Art. 9, 73), and workspace isolation with role-based access (Art. 14, 26). Compliance at this level is an instrumented system, not a policy as PDF.

Human oversight means AI serves people rather than replacing their judgment. It keeps a competent person meaningfully in control of an AI system, with the authority and the information to intervene, and it keeps that control in proportion to what is at stake. The deeper idea behind it is human-centricity: AI should support human judgment, respect autonomy and dignity, and remain accountable to the people it affects, not only the people who use it. The practical core is choosing the right oversight pattern for the stakes, because oversight that is too light fails to catch harm and oversight that is too heavy fails to scale.

The safest way to deploy an agent is to grant it the least autonomy that lets it do its job, then widen that autonomy only as evidence of reliable behavior accumulates. Progressive autonomy is to agentic governance what the three control layers are to the seven pillars of responsible AI: the operating discipline that turns a pillar into a practice. This article sets out a maturity model for agent deployment along three dimensions, decision authority, process autonomy, and accountability, and the controls that should be in place at each level.

AI governance is the system through which an organization makes responsible use of its AI and can prove it. It is not an ethics statement or a one-time project but an operating discipline that runs for the full life of every AI system the organization builds, buys, or embeds, carrying each responsible-AI principle down a chain from the harm that would breach it, through the risk and the control that reduces it, to the evidence that the control works.

Art. 9 requires providers of high-risk AI systems to establish, document, and maintain a risk management system that runs across the entire lifecycle. It is a continuous, iterative process: identify the known and foreseeable risks, estimate and evaluate them, and adopt targeted mitigation measures, updating the cycle as the system and its environment change. It is not a one-time pre-deployment assessment.

The OWASP Agentic Security Initiative Top 10 catalogs the security risks that autonomous AI introduces. It is written for security engineers, but the risks are governance problems, because they describe what an agent can be made to do rather than what it can be made to say. This article translates the agentic threat surface into the language of controls an AI Officer owns, and maps each risk to the responsible-AI pillar it stresses.

Under the EU AI Act, a provider develops an AI system or places it on the market under its own name; a deployer uses an AI system under its authority in a professional context. The roles carry very different obligations: providers bear the heavy technical duties (Art. 9-15, 19, 43, 48, 49, 72), while deployers bear a lighter operational set (Art. 26, 27). The same organization can be both at once, and determining your role per system is the first compliance step.

Micro-enterprises (fewer than 10 employees and turnover up to €2 million) can use a simplified compliance pathway under the EU AI Act, mainly for the provider role: simplified technical documentation (Art. 11.3) and a proportionate quality management system (Art. 17.3). The material obligations, the Art. 5 prohibitions, human oversight, and incident reporting, still apply in full.

Art. 12 requires high-risk AI systems to technically allow for the automatic recording of events (logs) over their lifetime. The logging must enable traceability of the system's functioning at a level appropriate to its intended purpose, support post-market monitoring, and help identify situations that may lead to risk or substantial modification. It is a design obligation on the provider that makes the system auditable by construction.

Art. 19 requires providers of high-risk AI systems to keep the logs that the system automatically generates (under Art. 12) for as long as they control them, for a period appropriate to the intended purpose and at least six months unless other law requires longer. It is the retention counterpart to the Art. 12 logging capability, and it works alongside the deployer retention duty in Art. 26.6.

Control-level compliance means satisfying the EU AI Act through engineered, evidenced controls rather than policy documents. The technical articles translate directly into system controls: automatic, retained logs (Art. 12, 19), a stop function to a safe state (Art. 14(4)(e)), input masking before the model as a GDPR and Art. 26(4) control, configurable block policies (Art. 26), risk scoring and incident reporting within deadline (Art. 9, 73), and workspace isolation with role-based access (Art. 14, 26). Compliance at this level is an instrumented system, not a policy as PDF.

The control environment for an AI agent is the set of enforced controls and governance arrangements that keep the agent inside agreed boundaries, and it rests on one distinction. Deterministic components, the orchestration, the checks inside tools, the permissions, and policy rules, apply explicitly coded rules predictably and can therefore carry enforceable controls. Probabilistic components, everything interpreted or decided through the language model, can only be influenced and evaluated statistically. Every control from the business process therefore needs an enforcement point outside the model, and a control that exists only in prompt text is an instruction, not an enforced barrier.

Under the EU AI Act, a provider develops an AI system or places it on the market under its own name; a deployer uses an AI system under its authority in a professional context. The roles carry very different obligations: providers bear the heavy technical duties (Art. 9-15, 19, 43, 48, 49, 72), while deployers bear a lighter operational set (Art. 26, 27). The same organization can be both at once, and determining your role per system is the first compliance step.

The EU AI Act assigns obligations on the assumption that the provider who builds a system and the deployer who uses it are distinct, stable roles. Agentic AI destabilises that assumption. A deployer who configures an agent with broad tool-calling rights, autonomous decision scope, or the ability to spawn sub-agents may be making changes substantial enough to carry provider-level obligations. Under autonomy, the question of who is answerable cannot be read off the contract. It has to be assessed against what the deployer actually configured the agent to do.

Art. 12 requires high-risk AI systems to technically allow for the automatic recording of events (logs) over their lifetime. The logging must enable traceability of the system's functioning at a level appropriate to its intended purpose, support post-market monitoring, and help identify situations that may lead to risk or substantial modification. It is a design obligation on the provider that makes the system auditable by construction.

Art. 14 requires providers to design and build high-risk AI systems so that they can be effectively overseen by humans during use. The system must let an overseer understand its capabilities and limits, watch for anomalies, resist automation bias, correctly interpret outputs, decide not to use the system, and intervene or stop it through a kill switch (Art. 14(4)(e)). It is the design obligation that makes the deployer oversight duty of Art. 26.2 possible.

Art. 19 requires providers of high-risk AI systems to keep the logs that the system automatically generates (under Art. 12) for as long as they control them, for a period appropriate to the intended purpose and at least six months unless other law requires longer. It is the retention counterpart to the Art. 12 logging capability, and it works alongside the deployer retention duty in Art. 26.6.

Art. 26.1 requires deployers to use high-risk AI systems strictly in accordance with the provider's instructions for use. This means using the system only for its intended purpose, within its specified technical configuration, and by qualified users, and documenting that compliance. Deviating from the instructions can shift liability entirely to the deployer.

Art. 26.2 requires deployers to ensure that the people assigned to oversee a high-risk AI system have the competence, training, and authority to do so effectively. Valid oversight is substantive, not formal: the overseer must understand the system, be trained on its limitations, and hold genuine authority to override its outputs.

Art. 26.4 requires deployers of high-risk AI to ensure that input data is relevant and sufficiently representative for the system's intended purpose. The deployer is responsible for data quality in operation, even though the provider sets the specifications under Art. 10.

Art. 26.5 requires deployers of high-risk AI to monitor the system's operation against the provider's instructions and to report risks and serious incidents. Monitoring is the early-warning mechanism that connects to incident reporting under Art. 73.

Art. 26.6 requires deployers of high-risk AI to retain the system-generated logs for at least six months, unless other law requires longer. The logs are the primary evidence that the system was used in accordance with its instructions.

Art. 26.8 requires deployers that are public authorities (or act on their behalf) to verify that a high-risk AI system is registered in the EU database before putting it into use, and to refrain from using it if it is not.

Art. 26.9 links the EU AI Act to the GDPR: where a data protection impact assessment (DPIA) is required under GDPR Art. 35, deployers of high-risk AI must use the information from the provider's documentation to support that assessment.

Art. 26(11) requires deployers of high-risk AI to inform the people who are subject to the system's decisions that a high-risk AI system is being used. This applies even where there is no direct interaction, such as CV screening or credit scoring.

The EU AI Act phases in between 2025 and 2028: the Art. 5 prohibitions and Art. 4 AI literacy applied from 2 February 2025, the Art. 50 transparency obligations from 2 August 2026, and the full high-risk obligations for Annex III systems from 2 December 2027 following the Omnibus amendments.

Agentic AI does not need a new kind of governance. Autonomy widens the gap between what a system does and who is accountable for it, which makes the existing governance chain, control tracing to risk and forward to evidence, more important, not less. The actions are real and sometimes irreversible, so the stakes on each control rise.

AI recruitment systems fall under Annex III of the EU AI Act as high-risk, which triggers the full deployer obligations of Article 26, human oversight, data quality, monitoring, log retention, and a Fundamental Rights Impact Assessment under Article 27. These duties cannot be transferred to the software vendor.

Control-level compliance means satisfying the EU AI Act through engineered, evidenced controls rather than policy documents. The technical articles translate directly into system controls: automatic, retained logs (Art. 12, 19), a stop function to a safe state (Art. 14(4)(e)), input masking before the model as a GDPR and Art. 26(4) control, configurable block policies (Art. 26), risk scoring and incident reporting within deadline (Art. 9, 73), and workspace isolation with role-based access (Art. 14, 26). Compliance at this level is an instrumented system, not a policy as PDF.

For SMEs, EU AI Act compliance is manageable but not optional: the Art. 5 prohibitions and Art. 4 literacy apply regardless of size, and SME deployers of high-risk AI carry the full Art. 26 obligations in proportionate form. Micro-enterprises gain administrative simplifications, not exemptions.

Under the EU AI Act, a provider develops an AI system or places it on the market under its own name; a deployer uses an AI system under its authority in a professional context. The roles carry very different obligations: providers bear the heavy technical duties (Art. 9-15, 19, 43, 48, 49, 72), while deployers bear a lighter operational set (Art. 26, 27). The same organization can be both at once, and determining your role per system is the first compliance step.

The AI Officer is the organization-wide director of responsible AI use, broader than a compliance role: it covers AI strategy, ethics, risk and literacy. The EU AI Act (Art. 26) makes the coordinating function necessary, but the need for an AI Officer extends beyond the law itself.

The EU AI Act assigns obligations on the assumption that the provider who builds a system and the deployer who uses it are distinct, stable roles. Agentic AI destabilises that assumption. A deployer who configures an agent with broad tool-calling rights, autonomous decision scope, or the ability to spawn sub-agents may be making changes substantial enough to carry provider-level obligations. Under autonomy, the question of who is answerable cannot be read off the contract. It has to be assessed against what the deployer actually configured the agent to do.

An audit trail for EU AI Act compliance is the structured, retained record, combining the system logs (Art. 12) with the deployer's own oversight and monitoring documentation, that lets you demonstrate to a supervisor that a high-risk AI system was used lawfully.

The EU AI Act and the GDPR create overlapping but distinct obligations for AI systems that process personal data. They align on data quality, impact assessments, transparency, and individual rights, but differ in scope, accountability roles, and incident-reporting timelines, so the efficient approach is integrated compliance, such as a combined DPIA/FRIA.

EU AI Act obligations per department depend on the risk class of the AI system. HR selection and credit scoring are high-risk (Annex III) and carry the full Art. 26 obligations; marketing AI and chatbots usually fall under the transparency obligation of Art. 50. A per-system Art. 6 analysis determines the exact obligation.

The first steps to EU AI Act compliance for deployers are: build an AI inventory, classify each system against Art. 6, request the provider documentation, start AI-literacy training under Art. 4, and assign ownership. These steps create the foundation for the Art. 26 obligations.

Deployers using GPAI models like ChatGPT or Copilot are generally not subject to the provider obligations of Art. 52-55, but two frameworks do apply: the Art. 50 transparency obligations and a high-risk use-case analysis. If the way you deploy the GPAI creates a high-risk AI system under Annex III, the full Art. 26 deployer obligations apply.

Micro-enterprises (fewer than 10 employees and turnover up to €2 million) can use a simplified compliance pathway under the EU AI Act, mainly for the provider role: simplified technical documentation (Art. 11.3) and a proportionate quality management system (Art. 17.3). The material obligations, the Art. 5 prohibitions, human oversight, and incident reporting, still apply in full.

A supplier checklist for AI procurement verifies what a provider must deliver before you can comply as a deployer: the instructions for use (Art. 13.3), the conformity declaration, the risk classification, update notification, and cooperation in a supervisory investigation.

AI governance is the system through which an organization makes responsible use of its AI and can prove it. It is not an ethics statement or a one-time project but an operating discipline that runs for the full life of every AI system the organization builds, buys, or embeds, carrying each responsible-AI principle down a chain from the harm that would breach it, through the risk and the control that reduces it, to the evidence that the control works.

An AI policy is the governance instrument that translates the EU AI Act's obligations into organizational commitments and accountabilities. An EU AI Act-aligned policy covers at least the scope, AI principles, the governance structure, the AI inventory and classification, the Art. 5 prohibitions, the approval process, human oversight, literacy, and incident reporting.

Agentic AI is AI that carries out a chain of actions on its own rather than producing a single output for a human to review. That shift does not add a new responsible-AI principle; it changes how every existing principle has to be governed. The human checkpoint moves from inside each decision to around the whole system: setting the bounds the agent operates within, monitoring the chain as it runs, and holding the ability to intervene.

An oversight log is the contemporaneous record that proves human oversight of a high-risk AI system under Art. 26.2 of the EU AI Act. It must capture, per oversight event, who reviewed the AI output, what they decided and why, and it must be retained for at least six months under Art. 26.6.

An oversight log is the contemporaneous record that proves human oversight of a high-risk AI system under Art. 26.2 of the EU AI Act. It must capture, per oversight event, who reviewed the AI output, what they decided and why, and it must be retained for at least six months under Art. 26.6.

Art. 27 requires certain deployers, public bodies and private deployers in defined sectors such as credit and insurance, to conduct a Fundamental Rights Impact Assessment (FRIA) before deploying a high-risk AI system, examining the impact on fundamental rights and the mitigation measures.

AI recruitment systems fall under Annex III of the EU AI Act as high-risk, which triggers the full deployer obligations of Article 26, human oversight, data quality, monitoring, log retention, and a Fundamental Rights Impact Assessment under Article 27. These duties cannot be transferred to the software vendor.

The AI Officer is the organization-wide director of responsible AI use, broader than a compliance role: it covers AI strategy, ethics, risk and literacy. The EU AI Act (Art. 26) makes the coordinating function necessary, but the need for an AI Officer extends beyond the law itself.

The EU AI Act and the GDPR create overlapping but distinct obligations for AI systems that process personal data. They align on data quality, impact assessments, transparency, and individual rights, but differ in scope, accountability roles, and incident-reporting timelines, so the efficient approach is integrated compliance, such as a combined DPIA/FRIA.

A Fundamental Rights Impact Assessment (FRIA) under Art. 27 is conducted step by step: describe the system and its purpose, identify affected persons, assess the impact on each fundamental rights dimension, define mitigation measures, and document the residual risk before deployment.

AI risk management is the practice of knowing which risks your AI systems carry and keeping them within bounds you chose deliberately. The risks are not abstract: each of the seven pillars of responsible AI has concrete ways it fails in practice, from a model that quietly disadvantages one group to a system whose accuracy decays after deployment. Managing them follows one repeatable pattern: recognize the risk, assess how likely and how serious it is for your system, and control it with measures you can test.

AI certification is not one category. Three different objects are assessed, each by a different kind of assessor: a person, an organization's AI management system, and an AI system placed on the EU market. The first two can be certified. The third is subject to a legal conformity assessment, which produces a certificate on one of its two routes and none on the other. Identifying which object a credential covers is the first step to judging what it is worth.

AI certification is not one category. Three different objects are assessed, each by a different kind of assessor: a person, an organization's AI management system, and an AI system placed on the EU market. The first two can be certified. The third is subject to a legal conformity assessment, which produces a certificate on one of its two routes and none on the other. Identifying which object a credential covers is the first step to judging what it is worth.

An SME that develops an AI system and makes it available to others is a provider under the EU AI Act and carries a substantially heavier burden than a deployer: for high-risk AI this includes a risk management system (Art. 9), data governance (Art. 10), technical documentation (Annex IV), conformity assessment (Art. 43), CE marking (Art. 48), and EU database registration (Art. 49).

AI certification is not one category. Three different objects are assessed, each by a different kind of assessor: a person, an organization's AI management system, and an AI system placed on the EU market. The first two can be certified. The third is subject to a legal conformity assessment, which produces a certificate on one of its two routes and none on the other. Identifying which object a credential covers is the first step to judging what it is worth.

An SME that develops an AI system and makes it available to others is a provider under the EU AI Act and carries a substantially heavier burden than a deployer: for high-risk AI this includes a risk management system (Art. 9), data governance (Art. 10), technical documentation (Annex IV), conformity assessment (Art. 43), CE marking (Art. 48), and EU database registration (Art. 49).

Art. 49 requires providers of high-risk AI systems to register the system in the EU database before placing it on the market. The database serves both market surveillance and public accountability, letting citizens see which high-risk systems are in use.

An SME that develops an AI system and makes it available to others is a provider under the EU AI Act and carries a substantially heavier burden than a deployer: for high-risk AI this includes a risk management system (Art. 9), data governance (Art. 10), technical documentation (Annex IV), conformity assessment (Art. 43), CE marking (Art. 48), and EU database registration (Art. 49).

Art. 50 of the EU AI Act sets four transparency duties: providers must ensure people know they are interacting with an AI system and must mark AI-generated content in a machine-readable way; deployers must inform people exposed to emotion recognition or biometric categorization and must disclose deep fakes and AI-generated text on matters of public interest. The obligations apply from 2 August 2026, with fines up to €15 million or 3% of global annual turnover, whichever is higher. One transition applies: generative AI systems already on the market before 2 August 2026 have until 2 December 2026 to meet the machine-readable marking duty.

The EU AI Act phases in between 2025 and 2028: the Art. 5 prohibitions and Art. 4 AI literacy applied from 2 February 2025, the Art. 50 transparency obligations from 2 August 2026, and the full high-risk obligations for Annex III systems from 2 December 2027 following the Omnibus amendments.

AI recruitment systems fall under Annex III of the EU AI Act as high-risk, which triggers the full deployer obligations of Article 26, human oversight, data quality, monitoring, log retention, and a Fundamental Rights Impact Assessment under Article 27. These duties cannot be transferred to the software vendor.

EU AI Act obligations per department depend on the risk class of the AI system. HR selection and credit scoring are high-risk (Annex III) and carry the full Art. 26 obligations; marketing AI and chatbots usually fall under the transparency obligation of Art. 50. A per-system Art. 6 analysis determines the exact obligation.

Deployers using GPAI models like ChatGPT or Copilot are generally not subject to the provider obligations of Art. 52-55, but two frameworks do apply: the Art. 50 transparency obligations and a high-risk use-case analysis. If the way you deploy the GPAI creates a high-risk AI system under Annex III, the full Art. 26 deployer obligations apply.

Ready-to-use transparency templates help deployers meet the EU AI Act information duties: a chatbot disclosure, an AI-generated-content label, and an Art. 26(11) notice for individuals subject to a high-risk system. The disclosure must be active and comprehensible at the moment of interaction.

Art. 51 sets out when a general-purpose AI model is classified as having systemic risk. A model crosses into the systemic-risk category when it has high-impact capabilities, which is presumed once the cumulative compute used to train it exceeds 10^25 floating-point operations (FLOP), or when the Commission designates it as such. Systemic-risk classification triggers the additional obligations of Art. 55 on top of the baseline Art. 53 obligations that apply to every GPAI provider.

Art. 52 sets out the procedure that connects to the systemic-risk classification of Art. 51. A provider must notify the Commission without delay, and within two weeks, when its general-purpose AI model meets or is foreseen to meet the systemic-risk threshold. The provider can argue, with the notification, that its model does not present systemic risk despite crossing the threshold. The Commission maintains and publishes a list of GPAI models with systemic risk.

Deployers using GPAI models like ChatGPT or Copilot are generally not subject to the provider obligations of Art. 52-55, but two frameworks do apply: the Art. 50 transparency obligations and a high-risk use-case analysis. If the way you deploy the GPAI creates a high-risk AI system under Annex III, the full Art. 26 deployer obligations apply.

Art. 53 sets the baseline obligations that every provider of a general-purpose AI model carries, regardless of whether the model has systemic risk. The provider must keep technical documentation of the model, provide information to downstream providers who integrate it, put in place a policy to comply with EU copyright law, and publish a sufficiently detailed public summary of the content used to train the model. These obligations have applied since 2 August 2025.

Art. 54 requires a provider of a general-purpose AI model established outside the EU to appoint, by written mandate, an authorized representative located in the Union before placing the model on the EU market. The representative is the Union-based point of contact that the AI Office and national authorities can address, and it holds the documentation and cooperates with supervision on the provider's behalf. It is the mechanism that keeps a non-EU model provider reachable under the Act.

Art. 55 sets the additional obligations that apply only to providers of general-purpose AI models with systemic risk, on top of the baseline Art. 53 obligations. These providers must evaluate the model using state-of-the-art protocols including adversarial testing, assess and mitigate systemic risks at Union level, report serious incidents to the AI Office without undue delay, and ensure an adequate level of cybersecurity for the model and its physical infrastructure. This is the regime for the small group of frontier models.

Regulatory sandboxes under Art. 57-61 are controlled environments, supervised by the national authority, in which organizations can develop and test innovative AI systems with guidance and temporary relief from certain administrative requirements, without suspending the material safeguards or incident-reporting duties.

Joining a national AI regulatory sandbox under Art. 57-61 follows a structured path: prepare a project dossier, apply in one of the submission windows, sign a sandbox agreement with the supervisor, report progress and incidents during testing, and produce a final report that supports full compliance afterwards.

Regulatory sandboxes under Art. 57-61 are controlled environments, supervised by the national authority, in which organizations can develop and test innovative AI systems with guidance and temporary relief from certain administrative requirements, without suspending the material safeguards or incident-reporting duties.

Joining a national AI regulatory sandbox under Art. 57-61 follows a structured path: prepare a project dossier, apply in one of the submission windows, sign a sandbox agreement with the supervisor, report progress and incidents during testing, and produce a final report that supports full compliance afterwards.

Joining a national AI regulatory sandbox under Art. 57-61 follows a structured path: prepare a project dossier, apply in one of the submission windows, sign a sandbox agreement with the supervisor, report progress and incidents during testing, and produce a final report that supports full compliance afterwards.

Art. 12 requires high-risk AI systems to technically allow for the automatic recording of events (logs) over their lifetime. The logging must enable traceability of the system's functioning at a level appropriate to its intended purpose, support post-market monitoring, and help identify situations that may lead to risk or substantial modification. It is a design obligation on the provider that makes the system auditable by construction.

Art. 9 requires providers of high-risk AI systems to establish, document, and maintain a risk management system that runs across the entire lifecycle. It is a continuous, iterative process: identify the known and foreseeable risks, estimate and evaluate them, and adopt targeted mitigation measures, updating the cycle as the system and its environment change. It is not a one-time pre-deployment assessment.

AI certification is not one category. Three different objects are assessed, each by a different kind of assessor: a person, an organization's AI management system, and an AI system placed on the EU market. The first two can be certified. The third is subject to a legal conformity assessment, which produces a certificate on one of its two routes and none on the other. Identifying which object a credential covers is the first step to judging what it is worth.

Art. 73 requires deployers and providers to report serious incidents involving high-risk AI to the competent market-surveillance authority without undue delay, within roughly 15 days for most incidents. An incident that is also a personal-data breach must additionally be reported under GDPR Art. 33.

AI certification is not one category. Three different objects are assessed, each by a different kind of assessor: a person, an organization's AI management system, and an AI system placed on the EU market. The first two can be certified. The third is subject to a legal conformity assessment, which produces a certificate on one of its two routes and none on the other. Identifying which object a credential covers is the first step to judging what it is worth.

Control-level compliance means satisfying the EU AI Act through engineered, evidenced controls rather than policy documents. The technical articles translate directly into system controls: automatic, retained logs (Art. 12, 19), a stop function to a safe state (Art. 14(4)(e)), input masking before the model as a GDPR and Art. 26(4) control, configurable block policies (Art. 26), risk scoring and incident reporting within deadline (Art. 9, 73), and workspace isolation with role-based access (Art. 14, 26). Compliance at this level is an instrumented system, not a policy as PDF.

Regulatory sandboxes under Art. 57-61 are controlled environments, supervised by the national authority, in which organizations can develop and test innovative AI systems with guidance and temporary relief from certain administrative requirements, without suspending the material safeguards or incident-reporting duties.

The EU AI Act and the GDPR create overlapping but distinct obligations for AI systems that process personal data. They align on data quality, impact assessments, transparency, and individual rights, but differ in scope, accountability roles, and incident-reporting timelines, so the efficient approach is integrated compliance, such as a combined DPIA/FRIA.

An AI policy is the governance instrument that translates the EU AI Act's obligations into organizational commitments and accountabilities. An EU AI Act-aligned policy covers at least the scope, AI principles, the governance structure, the AI inventory and classification, the Art. 5 prohibitions, the approval process, human oversight, literacy, and incident reporting.