EU AI Act for Developers — Practical Obligations for Building AI Systems

Are you developing an AI system — a chatbot, a recommendation engine, a CV screener — and wondering if the EU AI Act applies to you? Short answer: yes, if your software is deployed in the European Union. The regulation isn't just for big tech: it covers anyone who "places on the market" or "uses" an AI system. And if you misclassify, fines go up to 7% of global annual turnover.

Here at Meteora Web, we work with companies developing AI tools for the Italian market. We come from accounting and ERP backgrounds: compliance is a cost to be managed, not a flag to wave. This guide cuts straight to practical obligations for developers — no legalese, just actionable steps.

What obligations does the EU AI Act impose on AI developers?

The AI Act classifies AI systems by risk: minimal, limited, high, unacceptable. For developers, the workload changes depending on the level. Most custom systems (business chatbots, virtual assistants, spam filters) fall into minimal or limited risk, but beware: if your AI evaluates job candidates, approves loans, or diagnoses diseases, you are in the high-risk zone — and obligations become heavy.

Cross-cutting obligations for all systems (even minimal risk)

Even the most innocent chatbot must follow some rules:

• Transparency: you must inform the user that they are interacting with an AI system, not a human. A simple "This message is generated by an AI assistant" at the start of the chat suffices.
• Minimum technical documentation: you must be able to demonstrate to an authority (e.g., Data Protection Authority) how the model was trained, on what data, and what measures you took to avoid bias. For minimal-risk systems, a well-structured README with dataset provenance, performance metrics, and bias tests is enough.
• Cybersecurity: the AI Act requires systems to be “designed to ensure an adequate level of accuracy, robustness and cybersecurity.” Translated: no hardcoded passwords, no exposed API keys, no known vulnerabilities. If your model is public-facing, implement rate limiting and authentication.
• Concrete example: a client had a FAQ bot on WordPress. The AI Act forced us to document training data (historical FAQ) and add a disclaimer in the chat footer. One hour of work, zero fines.

How to correctly classify your AI system according to risk level?

Classification is critical: misclassifying a high-risk system as low-risk exposes you to fines. The regulation provides a taxonomy in Annex III listing high-risk areas: biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, immigration, justice.

If your AI system does not fall into these areas, you are outside high risk. But beware: even if not in Annex III, if your system performs profiling (processing personal data to evaluate aspects of personality or behavior), it may still be considered high risk if it significantly impacts individuals' rights. Case-by-case assessment is required.

Practical classification tools

The European Commission has published a self-assessment tool that guides you through a questionnaire. It's not legally binding, but it's a solid starting point. We use it with clients as a first check. Download the PDF from the official Commission website or use the web version. Answer questions about sector, purpose, data processed. You'll get a risk indication.

Immediate action: take the self-assessment tool, fill it out for your AI project. If it says "high risk" or "unclassified", stop and proceed to the next section.

What documentation do you need to be AI Act compliant?

Documentation is the operational core for developers. The AI Act requires two types:

• Technical documentation (Art. 11): describes architecture, training data, performance metrics, robustness and cybersecurity measures.
• Instructions for use (Art. 13): a manual for the user/deployer explaining features, limitations, expected behavior, and potential risks.

Minimum template for technical documentation

Don't reinvent the wheel. Here's a structure we use for our own projects:

# Technical Documentation AI System

## 1. Identification
- System name: Support Chatbot v2.1
- Version: 2.1
- Release date: 2025-03-15
- Developer: Company Name / Team

## 2. General description
- Purpose: Automate responses to FAQ on products
- Scope: e-commerce site, support area only
- Target users: end customers

## 3. Training data
- Sources: historical chat tickets (2019-2024), manual FAQs
- Volume: 5000 question-answer pairs
- Preprocessing: PII removal (names, emails, phone numbers)
- Metrics: accuracy 92%, F1-score 0.89

## 4. Architecture
- Model: BERT small fine-tuned
- Framework: Hugging Face Transformers
- Deployment: Docker container on private server, not public cloud

## 5. Robustness and cybersecurity
- Rate limiting: 10 requests/min per IP
- Authentication: API key with monthly rotation
- Logs: retained 90 days
- Bias tests: performed on sensitive question samples (e.g., “disability support”) – no bias detected

## 6. Lifecycle
- Update cadence: every 6 months with new data
- Retirement: planned at end of product life

Keep this file in a private Git repository. No need to publish. If an inspection comes, you show it.

What are the technical requirements for high-risk systems?

If your system is high risk (e.g., an AI tool for screening CVs for HR), obligations multiply. You must implement:

• Human oversight: a human operator must be able to intervene, stop, or override automated decisions. In code, this means a `human_review_required` flag that blocks automatic output for low confidence thresholds.
• Documented accuracy and robustness: demonstrate with repeatable tests that the system performs as expected. For a CV classifier, publish performance metrics on a separate validation set, and show no discrimination by gender or age.
• Automatic logging: every operation must be logged with timestamp, input, output, and operator ID (if human). Keep logs for at least 6 months.
• Error handling: the system must gracefully handle malformed or out-of-distribution inputs. For example, if a user submits a CV in an unknown format, the system should return a clear error message, not crash.

Code example: Human Oversight in Python

Here's a snippet implementing human override for a critical decision:

import logging

class AIHighRiskDecision:
    def __init__(self, threshold=0.8):
        self.threshold = threshold
        self.logger = logging.getLogger(__name__)

    def evaluate(self, input_data):
        # Simulate prediction with confidence
        confidence, decision = self._model_predict(input_data)

        if confidence < self.threshold:
            self.logger.warning("Low confidence (%s). Requires human review.", confidence)
            return {
                "status": "pending",
                "message": "Decision pending human review",
                "confidence": confidence,
                "suggested_decision": decision
            }
        else:
            self.logger.info("Auto decision with confidence %s", confidence)
            return {
                "status": "approved",
                "decision": decision
            }

This pattern is mandatory for high-risk systems under the AI Act: you cannot let AI decide alone when uncertainty exists.

How to manage AI Act compliance in an SME context?

We see it every day: Italian SMEs don't have a legal department. That's why we've integrated AI Act checklists into our development processes. Key points:

• Embed docs into CI/CD: every deployment updates technical documentation (version number, date, changelog) automatically. A simple Bash script or GitHub Action can handle it.
• Use open-source bias detection tools: libraries like fairlearn (Microsoft) or AI Fairness 360 (IBM) let you test your model on fairness metrics. Add them to your test pipeline.
• Train your team on the AI Act: you don't need a lawyer, but every developer must know what to do when the system produces a sensitive output. We run internal 30-minute sessions every quarter.

What to do now

Here are three concrete actions you can take today:

1. Classify your system: use the European Commission's self-assessment tool. If you're high risk, move to step 2.
2. Create or update technical documentation: use the template above and fill it for your project. It takes 30 minutes. Keep it under version control.
3. Implement human oversight: if your system makes automated decisions, add at least a confidence flag and a human review mechanism. Don't wait for the fine.

The AI Act is not a bureaucratic monster if tackled methodically. At Meteora Web, we've integrated it into our workflows for clients developing AI. For a broader overview, check our EU AI Act pillar guide.