For most EU-facing service firms, the AI Act already applies to you as either a provider or a deployer, and waiting for enforcement to catch up is the riskiest option on the table. Your first 90 days should focus on three things: classify every AI system you use or sell, lock down vendor contracts with no-training and data-location clauses, and put logging and human oversight in place. The enforcement timeline below tells you which deadlines matter most right now.
TL;DR:
- The Act reaches firms outside the EU when their AI outputs serve people there; firms may be deployers, providers, or both, depending on control.
- Treat hiring rankings and systems affecting access to jobs, credit, or essential services as high risk when humans do not meaningfully review decisions.
- Deployers must follow provider instructions, assign competent staff to oversee high risk systems, monitor operations, and retain logs for at least six months.
- Vendor agreements should bar training on prompts and outputs, limit retention, disclose subprocessors, and specify EU processing; GDPR terms apply when vendors handle personal data.
- Transparency rules start August 2, 2026; general high risk duties apply December 2, 2027, and serious violations can cost €35 million or 7% of turnover.
Table of Contents
- Who the AI Act Covers and What That Means for Your Firm
- Which Risk Tier Your Systems Fall Into
- The Articles That Define Your Obligations
- Your Compliance Checklist: Tasks, Owners, and Evidence
- How the AI Act Interacts with GDPR and Your Vendor Contracts
- When the Rules Bite: Enforcement Dates and Penalties
- Technical Controls Your Engineering Team Should Build
- How We Build Audit-Ready AI Systems for Regulated Firms
- Compliance Is an Enabler, Not a Blocker
- Autonomous Firm: Building Compliant AI Systems for Service Firms
- FAQ
- Sources
Who the AI Act Covers and What That Means for Your Firm
The AI Act’s scope under Article 2 catches almost everyone touching AI output that reaches people in the EU, regardless of where your firm is headquartered. If you built or customized the system and put it on the market, you are a provider. If you use someone else’s system in your own operations, you are a deployer, and most service firms fall into this second category even when they think of themselves as just “using a chatbot.”
A few concrete examples make the roles clearer:
- A CV-screening tool you bought from a vendor and configured for your own hiring: you are a deployer.
- A client-facing chatbot you built in-house and sell to other firms: you are a provider.
- A contract-automation plugin running inside software you license but did not build: you are a deployer, and the vendor is the provider.
- A pricing engine you commissioned a contractor to build exclusively for your firm: you are likely both, depending on how much control you retained over its design.
Ask three questions for every AI tool in use: who built it, who controls its training and updates, and whose name is on the output a client sees. Those answers tell you which obligations in the Act land on your desk versus your vendor’s.
Which Risk Tier Your Systems Fall Into
The Act sorts AI systems into four tiers, and the tier decides almost everything else: documentation, oversight, and how much it will cost you to stay compliant. Unacceptable-risk systems, such as social scoring or manipulative subliminal techniques, are banned outright and should never appear in a service firm’s stack. High-risk systems, covered in detail under the AI Act’s Annex III provisions, trigger the heaviest obligations because they affect fundamental rights, safety, or access to essential services.
For service firms, the mapping usually looks like this:
- HR screening or candidate ranking tools: typically high risk, since they affect employment access.
- Biometric identification or emotion-inference tools: high risk, and some biometric categorization uses are restricted outright.
- Client-facing advisory chatbots that don’t make final decisions: usually transparency-tier, not high risk, but still subject to disclosure rules.
- Billing automation, document summarization, and internal drafting assistants: typically minimal risk, with no special obligations beyond general good practice.
The decision rule that saves the most time: ask whether the system’s output directly determines a person’s access to a job, a loan, a service, or a legal outcome without meaningful human review. If yes, treat it as high risk until a compliance review says otherwise. If the system only assists a human who makes the final call, it usually sits in a lower tier.
The Articles That Define Your Obligations
A handful of articles do most of the work when you’re writing policies or answering an auditor’s questions. Article 9 requires a documented risk management process for high-risk systems, covering identification of risks and mitigation steps across the system’s lifecycle. Article 10 sets data governance standards for training and input data. Article 11 requires technical documentation detailed enough that a regulator could reconstruct how the system was built and tested, and Commission implementation guidance clarifies that providers can group tests across families of similar systems rather than rebuilding documentation from scratch for every variant, and remain responsible even when the system is delivered as SaaS through an interface.
Article 19 covers record-keeping, requiring systems to generate logs automatically. Article 14 requires human oversight measures proportionate to the system’s risk, meaning someone competent has to be able to understand, monitor, and if necessary override the output. For deployers specifically, Article 26 requires using the system according to the provider’s instructions, assigning competent staff to oversight, monitoring operation, and keeping logs for an appropriate period of at least six months unless other Union or national law requires longer.
Here’s what that means in practice:
- Your internal AI policy should name who owns risk assessment, who owns documentation, and who owns incident response, as three separate roles.
- Vendor contracts should require the provider to supply the technical documentation you need to meet your own Article 26 obligations.
- Logging and documentation duties apply now to any system already in production; the phased timeline mainly affects when regulators can act on noncompliance, not when the underlying duty starts.
Your Compliance Checklist: Tasks, Owners, and Evidence
Turning the Act into a sequence your team can actually execute means assigning owners and deadlines to each obligation, not just reading the text.
- Inventory and classify every AI system in use or under development, recording its risk tier, business owner, and documentation owner in a single register.
- Set an approved-tool policy that evaluates vendors on three axes: whether they train on your data, how long they retain it, and whether processing stays within the EU. Require no-training and retention-limit clauses in every new vendor contract.
- Build logging and monitoring into every high-risk and transparency-tier system, with a minimum six-month retention period and a named team responsible for log storage and review.
- Assign human oversight roles with documented competence and training, and set clear thresholds for when a human must review or override an automated decision.
- Document client and worker disclosures, including when and how you tell clients they’re interacting with AI, and keep a record of editorial review for any AI-generated content you publish under your firm’s name.
Pro Tip: Build your system inventory as a living spreadsheet with a review date column, not a one-time project; vendors change their training policies more often than compliance teams expect.
The output of this checklist should be a short dossier for each high-risk system: classification rationale, vendor contract terms, oversight assignment, and log retention policy, ready to hand to a regulator or an internal auditor on short notice.
How the AI Act Interacts with GDPR and Your Vendor Contracts
The AI Act doesn’t replace GDPR, it sits on top of it, and for most service firms the data-protection side of compliance is the harder problem. A data processing agreement under GDPR Article 28 is required whenever a vendor processes personal data on your behalf, and for AI tools that agreement needs to spell out training restrictions, retention periods, and subprocessor disclosure, not just generic security language.
Professional secrecy rules add another layer for lawyers, tax advisors, and health practitioners: many national frameworks already restrict what client information can leave a firm’s controlled environment, and an AI vendor that trains on prompts or stores data outside the EU often fails that test before the AI Act analysis even starts.
A fine of up to €35 million or 7% of worldwide annual turnover applies to the most serious AI Act infringements, which is the kind of number that should sit next to every vendor contract review.
Before signing or renewing any AI vendor agreement, check for:
- A no-training clause covering prompts, outputs, and any fine-tuning data.
- A defined, limited retention period with a deletion path you can verify.
- A commitment to EU-based processing, or equivalent safeguards if data leaves the EU.
- Clear subprocessor rules, so you know every party touching client data.
When the Rules Bite: Enforcement Dates and Penalties
The Act’s obligations don’t all land on the same day, and knowing which deadline applies to which rule is the fastest way to prioritize your work. Certain enforcement powers and prohibitions took effect first, with transparency obligations under Article 50 following on 2 August 2026. High-risk system obligations under Article 26 become fully applicable on 2 December 2027, and high-risk systems embedded in regulated products get until 2 August 2028.
- 2 August 2026: certain enforcement powers and transparency rules, including chatbot disclosure and AI-content labeling, start applying.
- 2 December 2026: additional transparency provisions come into force.
- 2 December 2027: high-risk system rules become generally applicable.
- 2 August 2028: high-risk systems embedded in already-regulated products reach full applicability.
Enforcement is split between the AI Office, which handles general-purpose AI models and very large platforms, and national competent authorities, who cover most deployer-level cases in their own member state. Penalties scale with the violation: the largest fines target prohibited practices and high-risk noncompliance, while lesser breaches of transparency or documentation duties carry lower but still material fines.
Technical Controls Your Engineering Team Should Build
Legal obligations only matter if your systems can actually produce evidence of compliance, which means engineering decisions and legal requirements have to be designed together. Start with a redaction pipeline that strips direct identifiers, names, client IDs, case numbers, before any prompt leaves your network for an external model; this single control does more for both GDPR and AI Act exposure than almost anything else on this list.
- Default to enterprise or business-tier vendor plans with contractual no-training guarantees and EU hosting, and verify retention settings directly in the admin console rather than trusting the sales page.
- Build immutable, timestamped logs for every high-risk and transparency-tier system, version your technical documentation alongside your code, and connect monitoring dashboards to alerts with a defined SLA for vendor response times.
- Treat your AI governance framework as a living document tied to your security architecture, not a static policy binder.
- Define an incident-response sequence in advance: capture evidence, trigger the vendor’s deletion path, notify affected internal teams, and assess whether the incident crosses a regulator-notification threshold.
A structured audit trail system, like the practices outlined in this AI audit trail guide, gives your compliance team something concrete to hand an auditor instead of a verbal description of “how it usually works.”
Pro Tip: Run a quarterly recheck of every approved vendor’s data policy; terms of service for AI tools change more often than most firms’ internal review cycles.
How We Build Audit-Ready AI Systems for Regulated Firms
We build AI-native systems for regulated sectors, and compliance is integrated into the build rather than added afterward. Our engagement modes pair your domain expertise with an engineering team that designs for data sovereignty from the start, including private or self-hosted LLM deployment, EU processing where required, and audit trails integrated into the system’s architecture.
For teams managing documentation and traceability across regulated workflows, our tax preparation AI checklist and HIPAA compliance checklist walk through the same operational patterns described in this article, applied to specific regulated workflows. Our monitoring approach for regulated teams addresses the oversight gap that most firms discover only after a system has been live for months.
- Compliance tools offer firms a structured layer for risk classification, documentation, and logging built into daily operations.
- Certain engagement modes can bring engineering capacity without adding permanent headcount.
- Deployment options exist to keep client data within the firm’s control boundary.
Compliance Is an Enabler, Not a Blocker
Treating AI Act compliance as an operational capability, not a one-time checklist, is what lets a firm scale automation safely instead of freezing in place. Firms with clear classification and logging built in can approve new client-facing automations in days instead of months, and they walk into client due diligence reviews with answers instead of apologies.
— Matevz
Autonomous Firm: Building Compliant AI Systems for Service Firms
Some firms invest directly in collaborations with service companies rather than selling one-time AI projects, pairing client expertise with engineering and compliance resources. Our Compliance OS and build modes are designed around data sovereignty from day one, with private or self-hosted LLM deployment so client data never leaves your control, and a team with backgrounds in ISO 27001, pharma, and finance building the governance layer alongside the automation itself.
If you’re ready to turn your firm’s expertise into an audit-ready, AI-native system, start the conversation on our Autonomousfirm partnership page.
FAQ
Does the EU AI Act apply to firms outside the EU?
Yes, the Act applies based on where the AI system’s output is used, not where your firm is headquartered, so a US or UK firm serving EU clients is in scope. This territorial reach mirrors how GDPR already applies to non-EU firms handling EU personal data.
What counts as a high-risk AI system for a service firm?
A system is typically high risk when its output directly affects a person’s access to employment, credit, legal outcomes, or essential services without meaningful human review. Common examples include CV-screening tools and biometric identification systems used in hiring or client verification.
How long must deployers keep AI system logs?
Deployers of high-risk systems must keep logs for an appropriate period of at least six months, unless other Union or national law sets a longer requirement, according to Article 26. Logs should be stored in a way that supports audits and incident investigations.
What are the penalties for noncompliance with the AI Act?
The most serious infringements can bring fines of up to €35 million or 7% of worldwide annual turnover, with lower but still substantial fines for lesser breaches. The AI Office and national competent authorities share enforcement responsibility depending on the system and the market involved.
How does Autonomousfirm help with AI Act compliance?
We design AI-native systems for regulated service firms with data sovereignty, private or self-hosted deployment, and audit-ready documentation built into the architecture from the start. Pricing depends on the engagement mode, Partnership, Venture, AI-native grant, or Funded build, and is available on request through our Autonomousfirm site.
Sources
- Article 26: Obligations of deployers of high-risk AI systems — AI Act Service Desk
- European Commission: enforcement of the AI Act
- Regulation (EU) 2024/1689 — The EU Artificial Intelligence Act (EUR-Lex)
- Implementation Guidance — EU AI Act (Commission guidance summary)
