AI Safety Compliance in Italy: A Guide to the EU AI Act for Local Startups

There is a moment in every Italian startup's life when a client — a bank in Milan, a hospital group in Bologna, a regional authority — asks for "documentation on your model." Until recently, that request had no fixed shape. Now it does. The EU AI Act gives it one, and parts of the regulation are already in force.

If you are four people in a coworking space in Turin training a system to inspect welds, or a Naples team shipping a customer-support assistant, this is for you. Not legal advice, but a map of what to check, in what order, and where the Italian pieces fit.

What already applies today

Since 2 February 2025, the prohibitions in the regulation have been enforceable: social scoring, manipulative techniques that exploit vulnerabilities, untargeted scraping of facial images, and several forms of biometric categorisation. There is no compliance path around these. If your product touches any of them, the answer is to change the product.

The same date triggered the AI literacy duty. Anyone working with these systems — your annotators, your sales team, your support staff — should receive training proportionate to their role. It sounds soft, but it is one of the few obligations that applies to nearly every company, and it is the easiest to document.

Since 2 August 2025, rules for general-purpose systems have applied. If you fine-tune an open model and release it under your own name, you may be treated as a provider at that layer. If you call a hosted API and build a product on top, you are usually a deployer, and the obligations stay lighter.

Most of the heavy duties for high-risk systems arrive on 2 August 2026, with a longer runway for systems that are safety components of products already covered by sector legislation. These dates have been the subject of active political debate, and proposals to adjust them have circulated. Before you build a budget around a specific date, confirm the current position with your lawyer or a compliance adviser.

Step one: classify yourself honestly

Nobody can tell you what to do until you know which box you are in. Two questions do most of the work.

Are you a provider or a deployer?

A provider puts a system on the market under its own name. A deployer uses it under its own authority — the classic case being an Italian company that buys a tool and runs it on its own customers. Providers carry the bulk of the documentation burden. Deployers still owe human oversight, staff training, and care with the data they feed in. Some companies are both, on different products.

Which risk tier?

• Prohibited practices — banned outright. No paperwork fixes this.
• High-risk — the list includes recruitment and worker management, credit and insurance scoring, education, essential public services, biometric identification and critical infrastructure. If you sell CV screening to Italian HR departments, you are here.
• Transparency obligations — chatbots, emotion recognition, biometric categorisation, synthetic media. Tell people what they are dealing with, label generated content, and be plain about it.
• Minimal risk — spam filters, stock forecasting, most internal tooling. No specific duties under this regulation, though privacy and consumer law still apply.

One warning: a system can be minimal risk here and still be a data protection problem. The Italian data protection authority has not been shy about acting on automated tools that touch personal data.

What the documents actually look like

For a high-risk system, expect to assemble and maintain roughly this set:

• A risk management system that runs continuously, not once before launch
• Data governance notes: where training data came from, what you checked, known gaps
• Technical documentation covering design, purpose, limitations and performance
• Automatic logging of events, so a decision can be reconstructed after the fact
• Human oversight measures — who can intervene, how, and how quickly
• Accuracy, robustness and cybersecurity testing, with the results kept
• Instructions for use, translated for the markets where you sell
• A quality management system, proportionate to your size
• Post-market monitoring and a route for reporting serious incidents
• An EU declaration of conformity, CE marking, and registration in the EU database

For most startups, the practical shortcut is to reuse what you already have. Your internal model card, your security questionnaire answers, your privacy records — these are raw material. The mistake is starting from a blank document.

A sequence a small team can follow

1. Inventory every system you ship or use, with a named owner for each. One spreadsheet is enough to begin.
2. Assign the tier and the role. Write one paragraph of justification you could defend to a client.
3. Pick the two or three lightest obligations that apply today and close them this month. Training and logging are good first targets.
4. Write the instructions for use in plain Italian and English. This single document answers most client questions.
5. Push obligations up the supply chain: ask your model vendor for documentation you can pass on.
6. Set a review date. The regulation, the guidance and your product will all move.

The Italian layer

Brussels sets the frame; Rome adds texture. The national cybersecurity agency has been assigned market surveillance duties, with the digital agency involved in supporting functions, and the division of labour is still settling. The data protection authority continues to work on automated decision-making and has published guidance on the topic. Italy has also adopted national legislation that sits alongside the EU framework, so secondary rules and implementing decrees are worth tracking if you sell into healthcare, work or public administration.

For public sector clients, expect procurement documents to ask for conformity evidence directly. A regional tender will not accept "we are working on it." Regulatory sandboxes are being set up at national level and are designed to give smaller companies supervised room to test, with priority access for startups and small enterprises. If your product sits near a high-risk line, this is worth pursuing rather than avoiding.

Contracts, clients and universities

Two habits save months of friction. First, put the roles in writing: who is provider, who is deployer, who handles incident reports, who owns the logs. Second, keep evidence as you go rather than reconstructing it later. Test results, meeting notes, the reason you chose one threshold over another — all of it becomes the file you hand over.

If you collaborate with a university or a research centre, agree before the project starts on what happens to the model afterwards. Research exemptions exist, but they end when you commercialise.

Where to start this quarter

Do three things. Build the inventory and give every system a tier. Run the training session and write down that you did it. Then take the highest-risk item on the list and produce one honest page on its limitations. That page will do more for your sales conversations than any slide deck — and it is the beginning of real compliance.

For anything with legal or financial consequences attached, talk to a qualified adviser who knows your sector. The framework is stable enough to plan around, but the details around your specific system are not something a website can settle.

Photo: Denise Cusack / Pexels