A useful EU AI Act guide should not begin with abstract principles. It should begin with the systems your organisation already uses, who owns them, what decisions they influence, and whether you can prove the controls around them. For compliance teams, the central problem is rarely a lack of policy. It is the absence of a reliable operating record.
The EU AI Act turns AI governance into an accountable management discipline. It requires organisations to assess their role in the AI value chain, classify relevant systems, apply obligations proportionately, and retain evidence that stands up to scrutiny. A spreadsheet may identify a handful of tools. It will struggle to show classification decisions, approval history, control testing, supplier commitments, monitoring results and board oversight in one defensible record.
EU AI Act Guide: Start With Scope and Role
The Act applies to providers, deployers, importers, distributors and authorised representatives in specified circumstances. An organisation outside the EU can still fall within scope where it places AI systems on the EU market, puts general-purpose AI models on the EU market, or uses AI system output in the EU.
Do not assume that purchasing an AI product removes responsibility. A company using an AI system in its employment, credit, healthcare, public-sector or other operational processes may be a deployer with material obligations. Equally, a business that materially modifies a third-party system, changes its intended purpose, or places it on the market under its own name may take on provider responsibilities.
This role analysis should be recorded system by system. One legal entity can be a deployer for an HR screening tool, a provider for an internally developed customer-risk model, and a distributor for a product incorporating a third-party AI feature. Applying one generic label to the whole organisation creates avoidable gaps.
Build an AI Inventory That Can Survive Challenge
An AI inventory is the foundation of compliance, but a list of software suppliers is not enough. Each record needs enough context to support a legal conclusion and an assurance decision.
At a minimum, capture the system name, business purpose, supplier or developer, owning business function, technical owner, data categories, affected individuals or groups, jurisdictions, deployment status, model type, integration points and decision impact. Record whether the system makes, recommends or materially supports decisions about people.
The inventory should also distinguish between approved, under assessment, pilot, retired and prohibited-use cases. This matters because shadow AI often enters through individual teams buying generative AI subscriptions or embedding model functions into existing SaaS products. A system cannot be classified, risk-assessed or monitored if the governance function does not know it exists.
Ownership must be explicit. Legal can interpret obligations, risk can challenge the assessment and information security can assess technical controls, but a named business owner must remain accountable for the use case and its continuing suitability. Where ownership is shared, define the decision rights rather than relying on a vague committee structure.
Classify by Prohibited, High-Risk and Other Uses
The Act is risk-based, but that does not mean every AI use requires the same governance burden. The first decision is whether a use falls within a prohibited practice. Prohibitions have applied since 2 February 2025 and cover specified practices, including certain manipulative or exploitative techniques, social scoring, some biometric categorisation, untargeted scraping of facial images, and certain uses of emotion recognition and predictive policing. The exact assessment depends on the facts, purpose and legal exception. Do not reduce it to a keyword search.
Next, assess whether the system is high-risk. Article 6 identifies two broad routes. The first covers AI systems that are safety components of products, or products themselves, subject to listed EU product safety legislation and third-party conformity assessment. The second covers systems used in listed Annex III areas, such as employment, education, access to essential services, law enforcement, migration, justice and democratic processes.
High-risk classification requires care. A system used in recruitment, for example, may be high-risk where it is intended to recruit or select natural persons, including filtering job applications or evaluating candidates. A generic writing assistant used by the HR team is not automatically high-risk simply because HR uses it. The intended purpose, functionality, impact and deployment context determine the answer.
For systems outside the prohibited and high-risk categories, obligations may be lighter, but not absent. Article 50 transparency duties can apply to certain systems that interact with people, generate synthetic content or create deepfakes. GDPR, employment law, consumer law, sector rules, contractual obligations and internal risk appetite continue to apply.
Convert Legal Duties Into Operating Controls
A classification result is only useful if it triggers a workflow. For high-risk systems, providers must establish a risk management system, data governance measures, technical documentation, record-keeping, transparency and instructions for use, human oversight, accuracy, robustness and cybersecurity. They must also operate a quality management system and complete the relevant conformity assessment before placing the system on the market or putting it into service.
Deployers of high-risk systems have their own practical obligations. These include using the system in accordance with instructions, assigning human oversight to competent people, monitoring operation, maintaining relevant logs, and informing the provider or distributor where serious incidents or malfunctioning indicate risk. In certain cases, deployers must carry out a fundamental rights impact assessment before use.
The compliance evidence should map directly to each obligation. A policy statement saying that humans remain in the loop is weak evidence. A stronger record identifies the override point, the designated overseer, competence requirements, escalation thresholds, training completion, logs reviewed and incidents raised. The same principle applies to data quality, bias testing, supplier due diligence and change management.
A proportionate control set will vary by system. A low-impact internal drafting tool may need approved-use rules, data restrictions, supplier review and periodic reassessment. A high-risk candidate-screening system needs more: documented intended purpose, data governance evidence, test results, human oversight design, user instructions, operational monitoring and a clear incident process.
Treat Suppliers as Evidence Sources, Not Assumptions
Many organisations will rely on third-party AI vendors. That does not eliminate the need for governance. It changes the evidence you need to obtain and assess.
Procurement and legal teams should establish what the supplier provides: technical documentation, intended-use statements, performance information, known limitations, human oversight guidance, logging capability, security documentation, change notifications and incident reporting commitments. The level of scrutiny should reflect the system’s risk and the organisation’s role.
Contracts should support the operating model. If a supplier can alter model behaviour without notice, the customer cannot reliably maintain its own assessment. If there is no route for reporting harmful outcomes or obtaining relevant logs, a deployer may be unable to meet its monitoring responsibilities. Commercial convenience is not a control.
For general-purpose AI models, obligations applicable from 2 August 2025 place significant responsibilities on model providers, including technical documentation and information for downstream providers. Organisations integrating such models should still assess their own application, prompts, retrieval data, guardrails and user journey. A compliant model does not automatically make a compliant system.
Make Monitoring and Change Control Routine
AI governance cannot end at launch. Performance can shift when data, users, prompts, suppliers, integrations or operating conditions change. A new feature may alter the intended purpose. A model update may invalidate testing. A business team may expand a tool from internal support into decisions affecting customers or employees.
Set review triggers in advance. Material model or supplier changes, incidents, complaints, performance degradation, new data sources, geographic expansion and changes to decision impact should all prompt reassessment. Periodic review remains necessary even where no trigger is raised.
The record should preserve what was approved, by whom, on what evidence and under which conditions. This is essential for internal challenge, regulator engagement and audit. It also prevents the familiar compliance failure where a system is assessed once, then quietly changes beyond recognition.
Report to the Board in Decisions, Not Technical Detail
Boards do not need a catalogue of every model parameter. They need a clear view of exposure, accountability and unresolved decisions. Useful reporting shows the total AI estate, systems by risk class, unknown or unassessed systems, prohibited-use findings, high-risk systems approaching deployment, overdue reviews, incidents, supplier dependencies and control exceptions.
The point is not to create another dashboard. It is to make risk ownership visible and force timely decisions on remediation, acceptance, suspension or retirement. A board report without supporting evidence is presentation. A report connected to an inventory, assessments, controls and audit trail is governance.
The main implementation challenge is coordination, not legal interpretation alone. Compliance, legal, risk, security, procurement, data protection and operational owners need one controlled process rather than separate registers and disconnected approvals. Endaxi AIG is designed around that requirement: a single system of record that connects inventory, classification, assessment, controls and audit evidence without turning AI governance into an expensive transformation programme.
Start with the AI systems already influencing people, safety, access or material business decisions. Establish ownership, make the classification judgement visible, and require evidence before deployment. That is the practical route from policy language to a governance position your organisation can defend.