EU AI Act Obligations for Regulated Firms: Audit-Ready Guide

Providers, deployers, importers, distributors, and authorized representatives all carry obligations under Regulation (EU) 2024/1689, and firms that develop AI for internal use can qualify as providers even when they never sell a product. The single action that most reduces regulatory risk right now is building a complete, auditable AI inventory, classifying every system by risk tier, and assembling a defensible evidence pack before an auditor or the AI Office asks for one. The EU AI Act obligations for regulated firms, explained plainly, come down to three pillars: know what you have, classify it correctly, and document it to the standard that Articles 16–27 and Article 49 registration demand.

Your immediate priorities:

• Inventory all AI agents and systems in use, including internally developed tools and third-party integrations
• Classify each system as prohibited, high-risk, transparency-risk, or minimal/no risk
• Assign a named compliance owner to each high-risk system
• Begin assembling technical documentation, automatically generated logs, and Fundamental Rights Impact Assessments (FRIAs) for high-risk systems
• Register required systems in the EU database under Article 49
• Confirm contractual rights with AI suppliers under Article 25(4)

Pro Tip: A tool like Aetherpulse can build your AI agent inventory automatically via OAuth metadata, without touching customer data, so your first evidence pack is ready before the auditor's first question.

Table of Contents

• What the EU AI Act covers and who falls within scope
• How to classify AI systems by risk tier
• Concrete obligations for providers and deployers of high-risk AI systems
• What GPAI model obligations mean for your firm
• Key dates, enforcement bodies, and penalties
• How to make your firm audit-ready for the AI Act
• How the AI Act interacts with GDPR, the NLF, and sectoral rules
• A 30/90/180-day plan for compliance owners
• Aetherpulse gives you audit-ready AI governance without the operational risk
• Sources

What the EU AI Act covers and who falls within scope

The AI Act's scope is deliberately broad. Understanding which role your organization occupies is the first scope test every compliance owner must run.

Operator definitions:

• Provider: any natural or legal person that develops an AI system or GPAI model and places it on the market or puts it into service under their own name or trademark. This includes firms that build AI for internal use only.
• Deployer: any natural or legal person that uses an AI system under their own authority in a professional context, except for personal non-professional use.
• Importer: an entity established in the Union that places on the market an AI system bearing the name or trademark of a person established outside the Union.
• Distributor: any entity in the supply chain that makes an AI system available on the Union market without placing it on the market themselves.
• Authorized representative: a natural or legal person established in the Union with a written mandate from a non-EU provider to act on their behalf for AI Act compliance purposes.

One organization can occupy multiple roles simultaneously. A bank that fine-tunes a third-party large language model and deploys it for credit decisioning is both a provider and a deployer for that system.

Extraterritorial reach is one of the Act's most consequential features for firms with US ties. Obligations can attach to providers and deployers located outside the EU when the output of their AI system is used within the Union. A US-headquartered firm whose AI-driven underwriting tool is used by EU-based staff or EU customers falls within scope. The Implementation Guidance confirms that obligations attach when a system is "put into service" even if it is never marketed, meaning internally deployed tools are not automatically exempt.

Scope test — run these questions for every AI system in your estate: Does the system's output affect persons located in the EU? Does your firm place the system into service under its own name? Does your firm modify a third-party AI system substantially enough to be treated as a new provider? If yes to any of these, obligations likely attach.

Free and open-source exemptions exist but are narrower than many firms assume. Open-source AI components lose their exemption once a provider monetizes them, places them into service under a brand, or integrates them into a product that is placed on the market. The Implementation Guidance provides the clearest current read on where the line sits.

How to classify AI systems by risk tier

The Act uses a four-tier model. Getting the classification right determines which obligations attach, so compliance teams need a repeatable decision framework, not just a list.

The four tiers:

1. Unacceptable risk (prohibited): practices that are banned outright from February 2, 2025. Examples include real-time remote biometric identification in public spaces (with narrow law-enforcement exceptions), social scoring by public authorities, subliminal manipulation that causes harm, and AI systems that exploit vulnerabilities of specific groups.
2. High-risk: systems listed in Annex I (AI embedded in regulated products such as medical devices, machinery, and vehicles) and Annex III (standalone high-risk use cases including biometric identification, critical infrastructure management, employment and worker management, access to essential services, law enforcement, migration, and administration of justice). For financial services firms, AI used in creditworthiness assessment, insurance risk scoring, and fraud detection in essential services can fall under Annex III.
3. Transparency risk: systems with contextual disclosure obligations but no full high-risk compliance burden. Chatbots must disclose they are AI. Deepfakes and AI-generated content must be labeled. Emotion recognition systems must notify users.
4. Minimal or no risk: the vast majority of AI systems, including spam filters, AI-assisted drafting tools, and recommendation engines in non-sensitive contexts. No mandatory obligations apply, though voluntary codes of conduct are encouraged.

Nine expressly prohibited practices compliance teams must screen for:

• Subliminal, manipulative, or deceptive AI techniques causing harm
• Exploitation of vulnerabilities of specific groups (age, disability, social situation)
• Social scoring by public or private entities that leads to detrimental treatment
• Real-time remote biometric identification in public spaces (outside narrow exceptions)
• Retrospective remote biometric identification (outside narrow exceptions)
• Biometric categorization inferring sensitive characteristics (race, political opinion, religion, etc.)
• Predictive policing based solely on profiling
• Emotion recognition in workplace or educational settings
• Scraping facial images from the internet or CCTV to build recognition databases

Decision framework for high-risk classification:

First, check whether the AI system is a safety component of, or is itself, a product covered by Union harmonization legislation listed in Annex I. If yes, high-risk obligations apply. Second, check whether the intended purpose matches a use case in Annex III. If yes, and if the system poses a significant risk of harm to health, safety, or fundamental rights, it is high-risk. Third, consider whether a substantial modification to an existing system has occurred, which can reset the classification clock.

High-risk systems must be registered in the EU database before deployment under Article 49. Transparency obligations under Article 50 apply separately and do not require a system to be high-risk; a customer-facing chatbot needs disclosure regardless of its risk tier.

Concrete obligations for providers and deployers of high-risk AI systems

Articles 16–27 of Regulation (EU) 2024/1689 set out the full obligation stack. The evidence auditors expect maps directly to these articles.

Detailed checklist for high-risk compliance:

• Risk management system: documented, iterative process covering identification, estimation, evaluation, and mitigation of risks throughout the lifecycle
• Data governance: training, validation, and testing datasets must meet quality criteria; data provenance and bias-testing records must be retained
• Technical documentation: must cover system architecture, design specifications, intended purpose, performance metrics, known limitations, and instructions for use
• Automatically generated logs: systems must log operation automatically; logs must be retained for at least six months (or longer where sectoral rules require)
• Post-market monitoring: a proactive plan to collect and analyze performance data after deployment, with defined thresholds for triggering corrective action
• Human oversight controls: technical and organizational measures ensuring a human can monitor, intervene, override, or halt the system; training records for oversight personnel
• FRIA: deployers in the public sector must complete a Fundamental Rights Impact Assessment; private-sector deployers in sensitive contexts are strongly advised to do the same
• Contractual duties under Article 25(4): written agreements with third-party component suppliers must specify the access, capabilities, and assistance the supplier will provide to enable the high-risk provider to comply

Pro Tip: Where your AI system is subject to existing Union harmonization legislation (for example, a medical device or machinery directive), Article 8 of the AI Act allows you to merge conformity assessment artifacts with those required under the sectoral rule, avoiding duplicative documentation effort.

Deployers carry a distinct but overlapping obligation set. Under Article 26, deployers must use high-risk systems in accordance with the provider's instructions, implement human oversight, monitor performance, and report serious incidents. For financial services firms, this maps closely to FCA SYSC obligations on systems and controls, creating an opportunity to consolidate governance artifacts. The AI Act compliance guide for financial firms on the Aetherpulse blog covers this crosswalk in detail.

What GPAI model obligations mean for your firm

General-purpose AI (GPAI) models, such as large language models used as a foundation for downstream applications, carry their own obligation set under Articles 53–55 of Regulation (EU) 2024/1689. These obligations fall primarily on GPAI providers, but downstream deployers must understand what to expect from their suppliers.

Article 53 requirements for all GPAI providers:

• Maintain technical documentation covering model architecture, training methodology, training data sources, and evaluation results
• Provide downstream developers with sufficient information to enable their own compliance, including model cards and capability disclosures
• Publish a public summary of training content, covering data provenance, major source categories, and processing steps applied
• Comply with EU copyright law and make available a summary of content used for training

Systemic-risk GPAI is a higher-obligation category triggered when a model is trained using a compute threshold of more than 10^25 floating-point operations, or when the AI Office designates a model as systemic-risk based on its capabilities. Providers of systemic-risk GPAI must additionally:

• Conduct and document adversarial testing (red-teaming) before deployment
• Report serious incidents to the AI Office
• Implement cybersecurity protections proportionate to the model's risk profile
• Maintain model risk management documentation covering mitigation measures

For deployers integrating GPAI-based systems: your supplier's compliance with Article 53 directly affects your own audit position. Before integrating any GPAI-based component, request the provider's technical documentation, training content summary, and model card. Absence of these documents is a red flag that your own downstream compliance may be compromised. The AI Office, operational from August 2026, can request this documentation directly from GPAI providers and require corrective measures.

ENISA's guidance on AI robustness and cybersecurity expectations reinforces that GPAI providers must treat adversarial robustness as a design requirement, not a post-deployment patch. Deployers should verify that GPAI components they integrate have been tested against adversarial inputs relevant to their use case.

Key dates, enforcement bodies, and penalties

The Act's obligations came into force on a phased schedule. Missing a deadline does not pause enforcement; it creates retrospective exposure.

Enforcement bodies operate at two levels. The AI Office handles GPAI models and cross-border enforcement, with powers to request technical documentation, evaluate models, and require corrective measures. National competent authorities handle high-risk AI systems within their jurisdictions, with powers to inspect, test, and order market withdrawal.

Penalties follow a tiered structure based on worldwide annual turnover or preset amounts, whichever is higher. Violations involving prohibited practices carry the highest fines. High-risk system violations and GPAI non-compliance carry lower but still material penalties. The Act includes proportionality provisions for SMEs and start-ups, but these do not eliminate the obligation to comply. Specific fine amounts are set out in Regulation (EU) 2024/1689 and vary by violation category.

The Annex III transition timeline means that some high-risk use cases in sensitive sectors have until December 2027 before full obligations apply, but firms should not treat this as permission to delay. Building governance infrastructure takes time, and auditors will expect to see documented progress well before the deadline.

How to make your firm audit-ready for the AI Act

Audit-readiness is not a one-time project. It is an ongoing operational state. The following numbered steps convert the Act's obligations into a repeatable evidence production process.

1. Build a complete AI inventory. List every AI system in use, including third-party tools, embedded AI in enterprise software, and internally developed models. Spreadsheet-based inventories are already inadequate for regulated firms; automated, read-only metadata collection is the current standard. Assign a named owner to each entry.

2. Classify every system by risk tier. Apply the Annex I and Annex III tests to each system. Document the classification rationale, not just the outcome. An auditor will ask why a system was classified as minimal-risk; the answer must be in writing.

3. Complete FRIAs for high-risk systems. The FRIA must be completed before deployment and updated when the system changes materially. For private-sector deployers, treat the FRIA as mandatory even where the Act technically permits discretion; regulators and courts will expect it.

4. Assemble technical documentation. Use the Annex IV template fields as your baseline. Each high-risk system needs a complete technical file covering architecture, intended purpose, performance benchmarks, known limitations, and instructions for use.

5. Enable automatic logging. Logs must be generated by the system itself, not reconstructed manually after the fact. Retain logs for at least six months. Where sectoral rules (such as FCA record-keeping requirements) demand longer retention, apply the longer period.

6. Implement and document human oversight controls. Define who can monitor, intervene, and override each high-risk system. Record training completed by oversight personnel. This is one of the most commonly cited gaps in AI Act readiness assessments.

7. Register high-risk systems in the EU database. Article 49 registration must occur before deployment for most high-risk systems. Maintain a record of the registration entry and any updates.

8. Package evidence for auditors. Evidence packs should be tamper-evident and cryptographically signed where possible. A manually assembled PDF folder is not sufficient for a sophisticated regulator. Read-only metadata collection avoids introducing new operational risks while producing defensible evidence.

Pro Tip: Use non-invasive, metadata-only collection to build your inventory and evidence packs. Invasive probes of production systems introduce new operational risks and can compromise the integrity of the evidence itself. Read-only approaches, like those used by Aetherpulse, produce the same auditor-facing output without touching customer data or inserting tooling into live systems.

For financial services firms, AI explainability requirements add a further layer: auditors expect to see not just that a human can override a system, but that the system's outputs are interpretable enough for that oversight to be meaningful.

How the AI Act interacts with GDPR, the NLF, and sectoral rules

The AI Act was designed to complement, not replace, existing law. For regulated financial services firms, this means governance artifacts can often be consolidated rather than duplicated.

Key interaction points:

• New Legislative Framework (NLF): the AI Act follows the NLF product safety model, which means conformity assessment, CE marking, and market surveillance procedures align with those used for other regulated products. Where a high-risk AI system is embedded in a product already subject to NLF legislation (listed in Annex I), Article 8 permits merging conformity assessment steps to avoid duplication.
• GDPR: the AI Act does not override GDPR. Where an AI system processes personal data, both regimes apply. Data governance documentation required under Article 18 of the AI Act (training data quality, bias testing, data provenance) overlaps significantly with GDPR's data protection impact assessment requirements. Firms should map these overlaps and produce a single consolidated record rather than two separate documents.
• FCA SYSC and Consumer Duty: for UK-based firms, FCA SYSC requirements on systems and controls and the Consumer Duty's outcome-testing obligations align closely with the AI Act's human oversight and post-market monitoring requirements. The FCA AI governance crosswalk on the Aetherpulse blog provides a practical mapping.
• ICO code of practice: the ICO's developing code on AI and automated decision-making will add further obligations for UK firms processing personal data through AI. Governance artifacts built for the AI Act will provide a strong foundation for ICO compliance.

Cross-border complexities for firms with US ties:

• A US-based provider whose AI system is used by EU-based deployers must appoint an authorized representative in the Union for high-risk systems
• The authorized representative holds a written mandate and is jointly responsible for compliance with the provider
• EU-based deployers using US-provider systems should verify that the provider has appointed an authorized representative and that Article 25(4) contractual terms are in place
• Where a US firm substantially modifies a third-party AI system before deploying it in the EU, it may be reclassified as a provider under the Act

When evaluating AI features embedded in enterprise software, the guidance on evaluating AI in ERP systems offers a useful procurement-side checklist for deployers assessing whether a vendor's AI components meet the documentation and transparency standards the Act requires.

Article 25(4) contractual requirements deserve specific attention. Written agreements with third-party component suppliers must specify the access, capabilities, and assistance the supplier will provide to enable the high-risk provider to comply. This should be a standard clause in every AI supplier contract, not an afterthought. Firms that lack these contractual rights will find it difficult to produce complete technical documentation when an auditor requests it.

A 30/90/180-day plan for compliance owners

Phased progress is what boards and auditors want to see. The following milestones convert obligations into measurable deliverables.

30-day priorities:

1. Complete a first-pass AI inventory covering all systems in use, including shadow AI and embedded AI in third-party tools. The AI inventory crisis is real; most firms discover significantly more AI systems than they expected.
2. Assign a named compliance owner to each system in the inventory.
3. Run the Annex I and Annex III classification tests for every system; document the rationale.
4. Identify systems likely to be high-risk and begin FRIA prioritization for those.
5. Confirm whether any systems involve prohibited practices; if yes, initiate immediate redesign or decommission.

90-day priorities:

1. Assemble technical documentation templates for all priority high-risk systems, using Annex IV fields as the baseline.
2. Enable automatic logging for high-risk systems; confirm retention periods meet the six-month minimum.
3. Draft quality management processes covering design, testing, and post-market monitoring phases.
4. Draft Article 25(4)-compliant contractual clauses for all AI supplier agreements; begin renegotiation where existing contracts lack these terms.
5. Complete AI literacy training for staff who interact with or oversee high-risk systems.

180-day priorities:

1. Complete conformity assessments for the highest-risk systems; engage a notified body where required.
2. Register all required systems in the EU database under Article 49.
3. Operationalize post-market monitoring workflows, including defined thresholds for triggering corrective action and a named responsible owner for each system.
4. Produce a first complete evidence pack for at least one high-risk system, covering all Article 16–27 deliverables, and present it to the board or compliance committee as a governance milestone.
5. Review and update all supplier contracts to include Article 25(4) terms.

Measurable evidence each milestone should produce:

• 30 days: signed-off AI inventory with risk classification rationale; list of systems requiring FRIA
• 90 days: technical documentation templates for priority systems; draft QMS; updated supplier contract clauses
• 180 days: completed conformity assessments; Article 49 registration records; first auditor-ready evidence pack; post-market monitoring plan

What governance teams actually get wrong in AI Act audits

The most common failure mode in AI Act readiness reviews is not a missing document. It is an incomplete inventory. Firms consistently undercount their AI estate because they rely on manual registers maintained by individual teams, with no systematic way to detect AI agents deployed through OAuth grants, API integrations, or embedded features in enterprise platforms. When an auditor asks for a complete list of AI systems and the compliance team produces a spreadsheet that was last updated six months ago, the credibility of every other document in the evidence pack is immediately in question.

The second most common failure is log retention that is manual, fragmented, or not tamper-evident. Reconstructing a decision trail from email threads and meeting notes is not what Article 19 contemplates. Automatically generated logs, retained in a form that cannot be retroactively altered, are the standard the Act sets and the standard auditors apply.

Contractual gaps are the third failure point. Firms that integrated third-party AI components before the Act came into force often lack the Article 25(4) rights to access the technical documentation they need to complete their own compliance. Renegotiating these terms takes time, and the absence of contractual access rights is a gap that cannot be papered over with internal documentation.

A well-structured audit evidence bundle for a regulated financial firm typically includes: a signed AI inventory with classification rationale, a completed FRIA, a technical documentation file aligned to Annex IV, automatically generated logs with retention records, human oversight protocols and training records, the Article 49 registration entry, and signed contractual terms with all AI component suppliers. Each document should carry a version number, a named owner, and a date of last review. Cryptographically signed evidence packs, where each document's integrity is verifiable, are the current best practice for firms that expect close regulatory scrutiny.

Aetherpulse gives you audit-ready AI governance without the operational risk

Compliance teams that have worked through the obligations above face a practical problem: assembling tamper-evident evidence packs manually is slow, error-prone, and introduces the very operational risks the Act is designed to surface. Aetherpulse is built specifically for this gap.

Aetherpulse connects to your AI estate via OAuth metadata only, building a complete agent inventory and identity graph without touching customer data or inserting tooling into production systems. It surfaces risk concentration, maps financial blast-radius exposure, and generates cryptographically signed (HMAC-SHA256) evidence packs aligned to Articles 16–27 and Article 49 registration requirements. The owner matrix and reporting templates are configurable to your governance structure, so compliance, legal, product, and security teams each see the deliverables they own. For firms with FCA SYSC, Consumer Duty, and ICO obligations alongside the AI Act, Aetherpulse's multi-framework hooks mean a single evidence layer covers multiple regulatory demands simultaneously.

Review Aetherpulse's pricing and deployment options to see how quickly your firm can move from manual registers to a defensible, auditor-ready governance layer.

Key Takeaways

The EU AI Act's obligations for regulated firms are determined by operator role and risk tier; the most defensible position is a complete, continuously maintained AI inventory backed by tamper-evident evidence packs aligned to Articles 16–27 and Article 49.

Sources

Compliance teams should consult these primary sources directly for authoritative text, implementation detail, and ongoing guidance updates.

• Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024
• AI Act | Shaping Europe's digital future - European Union
• Implementation Guidance for the EU AI Act
• AI Act annex 1 - AI Act Service Desk

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Recommended

• Preparing for an AI Governance Audit: A Practical Readiness Guide - AETHER Pulse
• EU AI Act Compliance for Financial Firms: 2026 Guide - AETHER Pulse
• AI Compliance Gap Assessment Guide for Regulated Firms - AETHER Pulse
• Why Regulators Audit AI Agents: A 2026 Compliance Guide - AETHER Pulse