Does the EU AI Act apply to your software? A plain-language guide

TL;DR — The EU AI Act can apply to you even if your company is not based in the EU, if your AI system is placed on the EU market or its output is used in the EU. The most useful first step is not "read the whole law"; it is to inventory every AI feature you use or sell, classify each one by purpose and risk, and separate "general-purpose AI" from "high-risk" and "prohibited" uses. Reading time: ~7 min

What it is and where it sits

The EU AI Act is a law that regulates certain AI systems and AI models based on risk. In plain language: it does not regulate "all software" and it does not ban "all AI." It creates buckets with different rules, from minimal obligations up to strict requirements and outright prohibited uses.

For a software customer, the practical question is usually not "Are we an AI company?" It is:

• Are we building or selling a feature that counts as an AI system?
• Are we using someone else’s AI inside our product or internal workflow?
• Is that use low-risk, high-risk, or prohibited?
• Are we acting as a provider (the party putting it on the market), deployer (the party using it), importer, or distributor?

Those roles matter because the obligations differ.

Where it sits in your architecture and business flow

The AI Act sits above your technical stack, but it attaches to very concrete parts of it: the feature in your app, the model API you call, the training data you use, the logs you keep, the human review step, and the business decision the output influences.

Typical flow:

User or staff member
        |
        v
Your app / workflow UI
        |
        v
Business logic decides when to call AI
        |
        +--------------------+
        |                    |
        v                    v
Rules engine / forms     AI model or AI API
        |                    |
        +---------+----------+
                  |
                  v
Output shown to human or used in decision
                  |
                  v
Action taken (approve, reject, rank, flag, summarize)
                  |
                  v
Logs, records, monitoring, audit trail

The law mainly cares about the right side of that diagram: what the AI does, how much it affects people, and whether there is enough control, transparency, documentation, and oversight.

What it replaces or changes

It does not replace privacy law, contract law, or sector rules. It sits alongside them.

• GDPR (EU privacy law) still applies if personal data is involved.
• Employment law still applies if you use AI in hiring or worker management.
• Medical device, product safety, financial, and consumer rules may still apply.

So the AI Act is usually an additional layer, not the only layer.

How it actually works

The mechanism is easier to understand if you treat it like a decision tree.

Step 1: Is this likely an AI system in scope?

Start with the feature, not the marketing label. If software generates, predicts, classifies, recommends, ranks, or influences decisions using model-based logic beyond a fixed hand-written rule set, it may be in scope.

A plain rules form like "if invoice > 10,000 send to manager" is usually not the hard case. A model that scores applicants, flags fraud, recommends who gets extra review, or generates customer-facing content is the hard case.

Step 2: What role are you playing?

• Provider (the party developing or placing the system on the market under its name): usually the heaviest obligations.
• Deployer (the party using the system in its own operations): still has real duties, especially for high-risk use.
• Importer/distributor: relevant if you bring someone else’s AI product into the EU market.

A common surprise: if you take a third-party model and package it into your own product under your brand, you may move closer to provider responsibilities for that productized feature.

Step 3: Which risk bucket fits?

At a high level:

• Prohibited uses: not allowed.
• High-risk systems: allowed, but with strict controls.
• Limited-risk / transparency cases: allowed, but users may need to be informed they are interacting with AI or seeing synthetic content.
• General-purpose AI model obligations: extra duties can apply to providers of broad models, especially powerful ones with systemic risk.
• Minimal-risk uses: usually little or no direct AI Act burden.

One realistic end-to-end example

Let’s walk through a realistic case: a company uses an AI feature to screen job applicants before a recruiter sees them.

The setup

• Candidates upload CVs on your careers site.
• Your applicant tracking workflow sends CV text to an AI API.
• The AI returns a score from 1 to 100 and a shortlist recommendation.
• Recruiters usually review only the top 20%.

Step-by-step classification

1. Identify the feature The feature is not "we use an LLM" (large language model, a broad text model). The feature is "AI scoring and ranking job applicants."

2. Map the impact The output affects access to employment. That is a major clue that this is not a casual low-risk use.

3. Check the risk bucket Employment-related AI used for recruitment, selection, or evaluating candidates is a classic high-risk area.

4. Decide your role

   • If you sell this hiring tool to employers under your brand, you are likely acting as a provider for that system.
   • If you are an employer using someone else’s tool internally, you are likely a deployer.

5. Translate that into obligations For high-risk use, the conversation changes from "Can we try this?" to "What documentation, human oversight, logging, testing, and instructions do we need before and during use?"

6. Check adjacent laws CVs contain personal data, so GDPR is also in play. Bias and discrimination concerns also matter under employment law.

7. Operational decision If you cannot explain how the tool is used, document its limits, keep logs, and provide meaningful human review, this is the point to pause deployment.

That is how the Act works in practice: not by asking whether AI is present, but by asking what decision it influences and how much harm it could cause.

When to use it (and when not to)

Use this checklist when deciding whether you need a serious AI Act review or just a light-touch record.

You probably don’t need a full-scale AI Act project if...

• The feature is not actually AI; it is a fixed rule or search filter.
• The AI output is purely assistive and does not materially affect people’s rights, access, safety, or opportunities.
• The system is a generic productivity helper and you are only a normal business user, not repackaging it into your own regulated product.

That said, even low-risk use can still create privacy, security, confidentiality, or contract problems.

Trade-offs

The AI Act is not just a legal checkbox. It changes product and operations choices.

A useful mental model: every benefit comes from adding control. Every control costs speed, money, or convenience.

In practice

The most useful thing you can do this week is create an AI system inventory and a feature intake form. You can do both in a spreadsheet, ticket template, or internal form tool.

⚠️ Do not wait until procurement signs a contract or engineering ships the feature. If a use case turns out to be high-risk or prohibited, undoing the rollout later can mean rework, customer disruption, or pulling a feature from production.

Example 1: AI feature inventory template

Use this as a CSV in Excel, Google Sheets, Airtable, or your internal governance tool.

system_name,owner_team,purpose,users_in_eu,y_n_personal_data,vendor_or_in_house,model_provider,output_used_for_decision,risk_area,likely_role,status,next_action
CV Ranker,HR Tech,Score and rank job applicants,yes,yes,vendor,Third-party API,yes,employment-high-risk,deployer,review-needed,legal-and-dpia-review
Support Chatbot,Customer Support,Answer common support questions,yes,yes,vendor,Third-party API,no,transparency,deployer,active,add-ai-disclosure
Marketing Copy Assistant,Marketing,Generate ad drafts,yes,no,vendor,Third-party API,no,minimal,deployer,active,record-vendor-docs
Invoice Routing Rules,Finance,Route invoices over threshold,yes,yes,in-house,none,no,not-ai,owner-check,active,no-ai-act-escalation

What it does: gives you a single place to list every AI-related feature and classify it by purpose, data, geography, and decision impact. Gotcha: teams often forget embedded AI inside SaaS tools they already use, so ask each department to list vendor features too, not just custom-built systems.

Example 2: Intake form for new AI features

This works as a JSON schema for an internal form builder or ticket workflow.

{
  "title": "New AI Use Case Review",
  "fields": [
    {"name": "feature_name", "type": "text", "required": true},
    {"name": "business_owner", "type": "text", "required": true},
    {"name": "describe_output", "type": "textarea", "required": true},
    {"name": "who_is_affected", "type": "textarea", "required": true},
    {"name": "used_in_eu", "type": "select", "options": ["yes", "no", "unknown"], "required": true},
    {"name": "personal_data_involved", "type": "select", "options": ["yes", "no", "unknown"], "required": true},
    {"name": "decision_about_people", "type": "select", "options": ["yes", "no", "possibly"], "required": true},
    {"name": "domain", "type": "select", "options": ["hr", "education", "finance", "health", "customer_support", "marketing", "security", "other"], "required": true},
    {"name": "vendor_name", "type": "text", "required": false},
    {"name": "human_review_step", "type": "textarea", "required": true},
    {"name": "logs_retained", "type": "select", "options": ["yes", "no", "unknown"], "required": true}
  ]
}

What it does: forces the project owner to answer the questions that matter for triage before build or purchase. Gotcha: if you leave "used_in_eu" or "decision_about_people" optional, people will skip them, and those are often the two answers that determine whether you need escalation.

Example 3: Simple internal decision rule

If your team uses a ticketing system, add a routing rule like this to your process documentation.

ai_review_routing:
  - if: "used_in_eu == yes AND decision_about_people in [yes, possibly]"
    then: "Route to compliance + legal before procurement or release"
  - if: "domain in [hr, education, finance, health]"
    then: "Flag as potential high-risk"
  - if: "vendor_name is not empty"
    then: "Request vendor technical documentation and permitted-use terms"
  - if: "logs_retained == no"
    then: "Block production rollout until logging plan exists"

What it does: turns vague policy into an operational gate your PM, procurement, and engineering teams can follow. Gotcha: this is a triage rule, not a legal determination; it should send risky cases for review, not pretend to settle them automatically.

Further reading

• EU AI Act text and recitals on EUR-Lex
• European Commission guidance on the AI Act
• The "High-Risk AI Systems" sections of the EU AI Act
• The "Automated individual decision-making" guidance in the European Data Protection Board materials
• NIST AI Risk Management Framework

This article was written by an AI system and published pending human review. Verify anything you intend to act on.