AI Policy Management for EU AI Act Compliance

Most organisations deploying AI tools already have some policies in place — acceptable-use rules, IT security standards, procurement checklists. The EU AI Act does not invent internal governance from scratch. It turns informal practices into documented, version-controlled obligations with a direct line to regulatory accountability.

What an AI Policy Actually Is — and What It Is Not

A policy is your organisation's internal rule. It tells employees what they can and cannot do with AI systems, who approves deployment decisions, how incidents get escalated, and what happens when a vendor's tool is flagged as high-risk.

A policy is not itself compliance. Writing an "AI acceptable-use policy" and posting it on your intranet does not satisfy Article 17. What satisfies Article 17 is a functioning quality management system — one in which documented policies and procedures are actually implemented, monitored, and kept current. The policy is evidence that the QMS exists; it is not a substitute for it. Regulators will ask for the document and proof that it operates: a version-history log, staff attestation records, and an audit trail of policy-triggered decisions.

That distinction — a policy as connective tissue between a statutory obligation and operational reality, not as a replacement for either — is the conceptual starting point for any AI governance programme.

The Core Policies Your Organisation Needs

Acceptable-Use Policy for AI Tools

This is the most immediate requirement, with the clearest short-term trigger: Article 4 (AI literacy) has applied since 2 February 2025. It requires that organisations ensure staff have sufficient knowledge to use AI systems competently, safely, and with awareness of risks.

An acceptable-use policy formalises that requirement. It defines which AI tools employees may use, which require prior approval, and which are outright prohibited because they fall under Article 5's banned practices. Without it, you cannot demonstrate Article 4 literacy — and you cannot control shadow AI.

Shadow AI is the situation where employees connect business data to external AI tools without any organisational approval or classification. Every unsanctioned tool is an unclassified AI system. If one falls in an Annex III category — say, it scores applicant quality or flags claims for review — the organisation is operating a potentially high-risk system without a risk management system, human oversight procedures, or documentation. An acceptable-use policy combined with an approved-tool inventory is the practical control that keeps shadow AI visible.

AI Governance and Oversight Policy

This policy defines how decisions about AI are made: who has authority to approve deployment of a new system, what the escalation path looks like when a system behaves unexpectedly, and how oversight responsibilities are assigned.

For high-risk deployers, Article 26 requires appropriate human oversight, monitoring of system operation, and retention of logs for at least six months (Article 26). A governance policy operationalises those obligations. It names the roles responsible for oversight, sets the review cadence, and specifies what triggers escalation to the provider or, where required, a report to the relevant authority.

Roles and Responsibilities

The EU AI Act distinguishes four roles — provider (Article 16), deployer (Article 26), importer (Article 23), and distributor (Article 24) — with different obligations attached to each. Article 25 adds a further complication: if you put your name on a high-risk system, substantially modify it, or change its intended purpose, you become a provider regardless of what you thought your role was.

A roles-and-responsibilities document maps every AI system in your inventory to the role your organisation holds and the specific obligations that follow. When a vendor updates a model, when you extend a system's use to a new function, or when you integrate an AI feature into your own product, that mapping needs revisiting.

Data and Model Governance Policy

Article 10 sets requirements for data governance: training, validation, and testing data must be subject to appropriate governance practices, covering data collection, processing, and an examination for biases. This is a data-governance obligation, not a staff-training one — staff competence requirements sit in Article 4, and the two are frequently confused.

For deployers who do not touch training data, the relevant obligation is ensuring you only deploy systems whose data provenance you understand well enough to fulfil your Article 26 duties. A data governance policy documents those standards and your process for verifying supplier claims.

Procurement and Vendor Policy

Before you sign a contract with an AI vendor, you are already making compliance decisions. If the vendor's system is high-risk under Annex III, they must have completed a conformity assessment (Article 43), produced Article 11 / Annex IV technical documentation, issued an Article 47 Declaration of Conformity, registered the system under Article 49, and affixed CE marking (Article 48). A vendor that cannot supply these is not compliant.

A procurement policy sets the due-diligence standard: which documents you require before deployment, what contractual representations the vendor must make, and how you verify them. For GPAI models specifically, Article 53 obligations (technical documentation, copyright policy, training-data summary for downstream users) have applied since 2 August 2025. Require that GPAI vendors demonstrate Chapter V compliance before you deploy.

Incident and Escalation Policy

For high-risk AI systems, Article 73 creates a provider-side duty to report serious incidents to the market-surveillance authority in the member state where the incident occurred. Timelines are strict: 15 days from awareness in most cases (Article 73(2)), 2 days for critical-infrastructure disruption or widespread infringement (Article 73(3)), 10 days if a person has died (Article 73(4)).

As a deployer, your duty under Article 26 is to monitor operation and notify the provider (and where required, the authority) of risks or incidents. An incident policy connects those obligations: it defines what constitutes an incident, who makes the initial severity call, what information must be captured immediately, and when the regulatory-notification clock starts.

Policies and the Article 17 QMS

Article 17 requires providers of high-risk AI systems to establish a quality management system — explicitly naming documented policies and procedures among its required components, covering strategy, design, quality control, and post-market monitoring.

Deployers have no direct Article 17 obligation, but those operating under ISO/IEC 42001 (the AI management system standard, which maps closely to the Act's QMS structure) will find the same policy infrastructure is required there too. Cross-mapping to ISO/IEC 42001 is an efficient way to build governance that satisfies both the Act and a market-recognised standard.

The key structural requirement is that all policies be living documents: version-controlled, reviewed at defined intervals, updated when obligations change. A policy still referencing 2 August 2026 as the high-risk deadline is factually wrong and potentially misleading.

Under the Digital Omnibus agreed in May 2026, the compliance deadline for stand-alone high-risk AI systems (the Annex III list) is now 2 December 2027. High-risk AI embedded in regulated products (Annex I) has until 2 August 2028. That is meaningful lead time. Building a functioning QMS — with policies, risk registers, technical documentation, and a conformity assessment — still takes longer than most organisations expect.

Mapping Policies to Obligations

The practical output of a policy-management programme is a matrix that links each internal policy to the Articles it evidences, the systems it covers, and the roles responsible for review.

Keeping this mapping current when new systems are deployed or obligations change is the operational heart of an AI governance programme.

How Confir Helps

Policies need an inventory and a classification before they can be mapped. Without knowing which AI systems your organisation runs, you cannot assign policies to them or verify that the right controls are in place.

Confir's rule-based classification engine registers every AI system you build or deploy, classifies each under Articles 5 and 6 using Annex III logic, and derives your role (provider, deployer, importer, distributor) from plain-English intake scenarios. The output is an organisation-wide risk register — the factual foundation on which policy mapping sits. The immutable audit log then records every classification decision, oversight action, and document version, turning a policy framework into something auditable rather than merely aspirational.

The deadline is 2 December 2027. That is enough time to build this properly if you start now.

Frequently Asked Questions

What is the difference between an AI policy and an EU AI Act obligation?

An obligation is the statutory duty imposed by Regulation (EU) 2024/1689 — for example, Article 9's risk management system requirement or Article 26's six-month log retention. An AI policy is your internal rule that operationalises that duty: it tells staff what to do, names who is responsible, and specifies what gets documented. The policy evidences that the obligation is being met; it does not replace the underlying operational practice. Regulators will ask for both the document and proof that it functions.

Does my organisation need AI policies even if we only use third-party AI tools?

Yes. As a deployer under Article 26, you are responsible for ensuring appropriate human oversight, maintaining logs, monitoring for incidents, and verifying that the systems you use were properly classified and documented by the provider. An acceptable-use policy and a procurement policy are the minimum controls that make those obligations manageable — and they are what prevent employees from introducing unsanctioned tools your organisation has never assessed.

Which Article requires a quality management system?

Article 17 requires providers of high-risk AI systems to establish a QMS. It explicitly calls for documented policies and procedures covering design, development, quality control, and post-market monitoring. Deployers have no direct Article 17 obligation, but those operating under ISO/IEC 42001 will find the standard maps closely to the same policy infrastructure.

What is shadow AI and why does it create EU AI Act risk?

Shadow AI refers to tools employees use without organisational approval or classification — consumer-grade assistants, external APIs, or productivity tools connected to business data. Every unclassified tool is a potential compliance exposure: if it falls in an Annex III category (employment decisions, creditworthiness scoring, etc.), the organisation may be operating a high-risk system without a risk management system, human oversight, or technical documentation. An acceptable-use policy combined with an approved-tool inventory is the primary control against this.

When do these policy obligations apply?

Article 4 (AI literacy, which includes the policy infrastructure that enables staff to use AI competently) has applied since 2 February 2025. The full high-risk obligation stack — including the Article 17 QMS requirement — applies from 2 December 2027 for stand-alone Annex III systems, under the Digital Omnibus agreed May 2026 (deferring the original 2 August 2026 date). High-risk AI embedded in Annex I regulated products has until 2 August 2028.

What are the penalties for inadequate AI governance policies?

Article 99 attaches penalties to obligation breaches, not to policy gaps as such — but a non-functioning QMS (Article 17), inadequate oversight procedures (Article 26), or missing required documentation are substantive breaches. The fine ceiling for most high-risk obligation failures is €15,000,000 or 3% of global annual turnover, whichever is higher (Article 99(4)). Article 99(6) caps fines for smaller companies at the lower of the percentage or the fixed amount — a proportionality protection, not an exemption.

How often should AI policies be reviewed?

The Act sets no single interval, but Article 17's QMS requirement implies procedures must stay adequate and current. In practice, review whenever a new system is deployed, a vendor updates a model, the regulatory framework changes, or an internal audit reveals a gap. Annual reviews are a minimum. For organisations with active AI adoption, quarterly checks on the system inventory are realistic.

Related guides

• risk classification under Articles 6-11
• SMB compliance obligations
• EU AI Act compliance checklist
• compare governance software platforms
• Article 6 risk classification tool
• AI governance infrastructure requirements
• risk management tool comparison
• high-risk healthcare AI systems