AI in Italian Schools: Starting Under DM 166 Without Waste

If you run an Italian school or manage its administration, AI is no longer a grey zone: it's your responsibility, with dedicated funds. Here is what the rules ask for in plain words, the questions to put to a vendor, and how to start with a single process without burning the fund.

What It Is

The Italian Ministry of Education guidelines (DM 166/2025) make principals and administrative directors (DSGA) formal deployers of AI systems. A deployer is whoever puts a system into use: they must be able to assess it, monitor it and, if needed, switch it off. It's not a title, it's a role.

DM 219 put money next to the mandate: €100 million from the PNRR recovery plan, up to €50,000 per school.

Why It Matters

Until recently, some teachers used AI in class, others banned it, and almost nobody knew who was accountable. Now the question is no longer "can we use it?" but "which system can we run without creating a liability?"

In a company, the deployer is often the head of IT. In a school it's the principal, with teaching staff, families, minors and sensitive data. A system that "helps teachers" without saying how it decides, on which data and who can verify it, can't be adopted. Not out of caution: by law.

On top of that, the EU AI Act treats many education uses as high-risk: student assessment, admission, assignment to learning paths. Even a product sold as a "tutor" or "teaching assistant" can get close to that line. It must be clarified before the first pilot, not after.

And €50,000 looks like a lot from outside. From inside it covers little if you buy a closed product with a yearly fee, extra training and data leaving the EU.

Three Questions Before Installing Anything

We always start here. If one has no answer, nothing gets installed.

1. Who is responsible for the system? By name.
2. Which data does it touch? And where does it live?
3. How do you prove, to an inspector or a parent, that it does what it claims?

Then every system must be:

• Assessable: the principal opens a report and sees what the system did this week. How many sessions, which classes, which materials, where it got things wrong.
• Monitorable: a log, not a marketing dashboard. Who has access, who exported, when a module was switched off.
• Switchable off: if a teacher flags a wrong output about a pupil, the path stops. Right away, not "we've opened a ticket with the vendor".

We've seen public tenders won and then frozen because the vendor couldn't answer these three. The feature was there. The accountability wasn't.

How to Do It

1. Pick one process. Differentiated teaching, or personalised learning plans (PDP), or a helpdesk for teachers. Not three at once.
2. Measure first. How many hours it takes today, where materials get lost, which mistakes come back every term.
3. Map the data. Who touches it, where it lives, which uses are high-risk and which aren't. Only then choose or write the software.
4. Build one visible piece in a few weeks, not a three-year plan. Staff must be able to use it. If they don't, stop.
5. Write down who is responsible. By name, with logs, before the first student logs in.
6. Train on the real flow. Not an "intro to AI" course, but one hour on how to load a unit, fix an error and switch it off. If that hour isn't enough, the product is wrong.

The schools we work with don't ask for a chatbot. They ask for a tutor built on the materials they already use, with different levels and the teacher in charge; a tool for personalised plans instead of scattered Word files; and data that stays in the EU, ideally under the school's own control, with named access and limited retention.

Ready to copy. Paste this into Claude or ChatGPT to draft an email to a vendor:

Try It Small

In ten minutes, take the AI system you already use, or the one you've been offered, and try to answer the three questions: owner, data, proof. Then ask the simplest one: if a teacher flags a mistake about a pupil tomorrow, who switches off what, and how? If nobody knows, you've found your first job, before any purchase.

Three Mistakes We've Seen

• The turnkey tutor. Teachers and pupils use it, pupils paste in their homework. Three weeks later a family asks which data left, to whom, and whether it can be deleted. The vendor answers with an FAQ in English. The principal switches everything off. The €50,000 was committed; the system wasn't.
• The pilot without logs. One class, it goes well. When it extends to three sites nobody knows who has access: two shared accounts, a password in an email.
• The committee that never chose. Slides, meetings, no process picked. Six months later, zero use. The fund expires and generic training gets bought to have "done something". That's not adoption, it's a report.

All three are avoided the same way: one process, one owner, one data perimeter, one visible piece. Before the yearly fee.

Watch Out For

• Teachers aren't the obstacle: they ask for precise things. Their own materials, seeing the steps, being able to say no to an output, and keeping the time saved instead of turning it into more reports.
• A system that hides its reasoning becomes either an oracle or an enemy. You need a visible trace: source, level, suggestion. No "the AI said so" without a source.
• The model is a second-level choice: Claude, GPT or a local model comes after governance. If data can't leave, read when local AI is worth it.
• A slide is not an answer. That goes for every question to the vendor.

We build custom systems for schools: the code belongs to the school or body that pays for it, and so does the data. To put the process in order before choosing any tool, start with an audit before the model.

In short: In schools you start from governance, not features: one process, a named owner, data under control and a system that can be switched off.