AI in Italian schools: from DM 166 to the first real deployments

Until recently, AI in many Italian schools sat in a grey zone. Some teachers used it. Others banned it. Almost nobody knew who was accountable.

The Ministry of Education guidelines (DM 166/2025) closed that zone. Principals and administrative directors are now formal «deployers» of AI systems. That is a role: whoever puts a system into production must be able to assess it, monitor it, and switch it off.

DM 219 put money next to the mandate. €100 million in PNRR funds. Up to €50,000 per school. The question is no longer «can we use AI». It is «which system can we run without creating a liability».

What «deployer» means in a school

In a company the deployer is often a CTO. In a school it is the principal. Public office, teaching staff, families, minors, sensitive data.

A system that «helps teachers» without saying how it decides, on which data, and who can verify it, is not adoptable. Not from caution. From law.

The EU AI Act treats many education uses as high-risk. Student assessment, admission, learning-path assignment. Even when the product is sold as a «tutor», the line is thin. It has to be declared before the first pilot.

We start from three questions. Who is responsible for the system. Which data it touches. How you show a parent or an inspector that it does what it claims.

If one of those three has no answer, nothing gets installed.

The funds arrive. The software does not

Fifty thousand euros per school looks large from outside. Inside it disappears if you buy a closed product with a yearly fee, extra training, and data leaving the Union.

The schools we work with do not ask for a chatbot. They ask for three concrete things.

A didactic tutor built on materials already in use, not a generic corpus. Same programme, different levels. The teacher decides. The system proposes.

A tool for personalised learning paths. Plans, adaptations, evidence. What today lives in scattered Word files.

Data that stays in the EU. Better: under the school's control. Accounts, logs, backup, deletion.

The real constraint is not the model

Choosing Claude, GPT or a local model is a second-level decision. Governance comes first.

Every system must be assessable. A principal opens a report and sees what the system did this week. Sessions, classes, materials, errors.

It must be monitorable. Who accessed it. Who exported. When a module was switched off.

It must be killable. If a teacher flags a wrong output on a pupil, the path stops. Not «we opened a ticket with a US vendor».

We have seen public selections won and then frozen because the vendor could not answer these three. The feature existed. Accountability did not.

What we are putting into production

We work with Italian schools on compliant software, not demos.

Tutors use the school's materials. The teacher sees the trace. No «the AI said so» without a source.

Pupil and family data stay in the agreed perimeter. EU hosting. DPA. Named access. Limited retention.

The principal gets a deployer view: system status, usage logs, kill switches. That is the product, not an extra.

The slow work is upstream. Process map. Who touches data. Which uses are high-risk. Only then do we write software.

How to start without burning the fund

A school should not «adopt AI». It should pick one process. Differentiated teaching, or personalised plans, or a teacher helpdesk. Not three at once.

Measure first. Hours spent today. Where materials get lost. Which errors return every term.

Build one visible piece in weeks, not a three-year plan. The staff must use it. If they do not, stop.

Write who is responsible. By name. With logs. Before the first student login.

If this order feels slow, it is the opposite. It is the only one that stays on after an inspection.

If you are choosing a vendor, ask where the data lives, who the deployer is in the contract, and how a module is switched off. A slide is not an answer. We build systems the school owns. If you want to see how we set governance before software, write to us.