AI governance in an SME: the controls that make a use case defensible

There's a question that comes before choosing the tool and one that comes after. The first — "do I have to comply with the AI Act? am I obliged?" — we tackled in the article on the EU AI Act for SMEs, and for most businesses the answer is calmer than expected. This is the other one: once you have decided to put a use case into production — a sales copilot, a support bot, an automation in administration — how do you govern it so that it holds up? Holds up to an inspection by the Garante, to a customer's request, to an incident, to an auditor's uncomfortable question.

It's a different question from formal compliance, and it's the one where we see the most carelessness. Not "am I in order with the law?", but "if something goes wrong, what can I show?". The difference between the two is all of governance. Let's try to put it in order, in plain language, without scaremongering and without turning it into the usual twenty-page document nobody reads.

Governance isn't a document: it's a block that accompanies every use case

The most common mistake is to think of AI governance as a general policy — a PDF that declares principles and ends up in a folder. It doesn't work like that, because risk doesn't live in the company in the abstract: it lives in the individual workflow. A copilot that suggests support replies and a system that screens incoming CVs have the same "level of company attention", but an incomparable risk profile. Serious governance attaches to the use case, not to the organisation.

What we use — and it's the structure we recommend to any SME, even without us — is a short, repeatable block that accompanies every workflow design. Five lines, always the same:

• Risk level — where the use case falls on the AI Act's scale (almost always minimal or limited; high only for personnel, credit, biometrics).
• Is a DPIA needed? — the GDPR check on the processing of the personal data involved (see below: when it's triggered and why the "standard" one isn't enough).
• Risk labels — a classification of the ways that workflow can fail, with a shared vocabulary rather than words (see the MIT taxonomy further on).
• Mitigations — what we put around the risk: thresholds, autonomy limits, human review, data minimisation.
• Oversight and traceability — who watches over operations and what stays recorded, and for how long.

The value of this block isn't formal: it's operational. When the Garante, a customer or an auditor asks "how do you manage this system?", you don't answer with a philosophy — you open the specific workflow's block and show the five lines. It's the difference between declaring you're governed and actually being so.

The DPIA for AI: when it's needed, and why the "standard" one isn't enough

The data protection impact assessment (DPIA, art. 35 GDPR) is governance's first concrete tool, but it's also the most misunderstood. It isn't always needed: it becomes mandatory when the processing is "likely to be high risk". Three cases make it automatic — automated decisions with legal or significant effects on the person, large-scale processing of special categories of data (health, opinions, biometrics), and systematic monitoring of publicly accessible areas — to which the EDPB adds nine supplementary criteria (profiling, evaluation, use of innovative technologies). Most corporate AI deployments touch at least one.

So far it's classic GDPR. The point that almost no model takes into account is that a generic DPIA, designed for a database or an ERP, misses AI's own risks. A model isn't a table: it has behaviours a traditional assessment doesn't anticipate. In a DPIA for AI you have to add, as a dedicated section, at least four items that don't exist elsewhere:

• Model opacity — the decision may not be explainable line by line. If the workflow affects a person, "I don't know why it decided that way" is a compliance problem, not just a technical one.
• Drift — a model that worked well degrades over time if the input data change. A check done once at launch isn't enough: it must be redone.
• Memorisation of training data — a model can regurgitate fragments of the data it was trained on, including personal information. It's a breach vector a database doesn't have.
• Conflict with the right to be forgotten — deleting a personal datum from a database is trivial; "unlearning" a datum from an already-trained model often isn't. The DPIA must state what you do when that request arrives.

If your consultant offers you the DPIA they'd use for any software, without this section, they're giving you a form, not an assessment. And if the DPIA finds a high risk you can't mitigate, the GDPR (art. 36) requires you to consult the supervisory authority before proceeding: rare for an SME, but it should be planned as an escalation branch, not discovered after an incident.

A shared vocabulary for risk, instead of words

"This system is risky" isn't useful information: it's an impression. The step up in governance is moving from vague prose to a repeatable, citable label, the same for all workflows, so that two different use cases can be compared. That's why we use, as a reference vocabulary, the MIT AI Risk Repository, which classifies risk along two axes:

• How the risk arises (causal axis): the entity that generates it (human / AI / other), the intent (intentional / unintentional), the timing (before or after deployment).
• What kind of risk it is (domain axis): seven domains — discrimination, privacy and security, misinformation, malicious use, human-machine interaction, socioeconomic effects, system failures and limitations.

An example makes the method concrete. A sales copilot that occasionally "invents" a detail about a product — the classic hallucination — is labelled as (entity: AI · intent: unintentional · timing: after deployment) × (domain: misinformation). It's not an academic affectation: that label tells you where to act (downstream, with a human check on the output before it reaches the customer) and gives you a common word to discuss it with people who don't understand the model. Prose doesn't do that: the label does.

The two operational controls that count more than all the others

You can write elaborate governance and stay exposed; or keep a lean one with two solid controls and be genuinely defensible. In almost every SME use case, these two make the difference.

The first is the human in the loop. Not as a slogan, but as architecture: who watches over the system's operation, with what authority to stop it, and on which decisions their sign-off is mandatory. It's the same principle that makes an agent defensible in administration and finance — where the outcome is irreversible because it moves money — but it holds wherever a decision touches a person. The practical rule we give: grant the system autonomy only where the outcome is reversible and verifiable; everything else goes through a person.

The second is traceability. For high-risk uses the AI Act requires the deployer to keep logs for at least six months and to report serious incidents; but even outside that perimeter, keeping track of what the system decided, on which data and who approved is what turns "we trust it" into "we can prove it". A record that will stand up to an inspection, not a prompt. It's the cheapest control to put in place and the most expensive not to have when you need it.

The Italian frame: compliance is a living area, not a checkbox

Anyone who sells you "once and for all" governance isn't watching what's happening in Italy. Law 132/2025 introduced the country's general principles on AI and extends the scope of the DPIA for artificial-intelligence uses beyond the GDPR base — which means the current requirements must be checked before citing them to a client, because the text is recent and the subject is moving. On the enforcement front, Italy's data-protection authority (Garante Privacy) is in 2026 actively inspecting the use of AI in some sectors: enforcement is real, not theoretical. The Garante's AI page is the canonical source to re-check on every project, because its guidance is updated often.

The practical reading: governance isn't a document you sign and file, it's a practice you revisit. A model drifts, a rule changes, a use case expands — and the five-line block must be reopened. Anyone who sells it to you as a box ticked once is reassuring you, not protecting you.

From orienting to doing, in practice

If you're about to put a use case into production and want it to hold up, the path is short and ordered:

• Attach the block to the workflow, not to the company — risk level, DPIA yes/no, labels, mitigations, oversight. Five lines for each use case, not a PDF for the whole company.
• If a DPIA is needed, use one with the AI section — opacity, drift, memorisation, the right to be forgotten. Without those items it isn't an AI assessment, it's a form.
• Give the risk a label, not an adjective — a shared vocabulary makes cases comparable and mitigations obvious.
• Put human-in-the-loop and traceability in from day one — they don't slow the project down: they make it defensible. They're the two controls worth more than all the written policy.
• Treat it as living — re-check the model, the Italian law and the scope of use at intervals, not once at launch.

Even before that, though, it's worth knowing where you are: our AI-readiness assessment helps you understand which department to start from with more return and less friction, and which controls to put around the first workflow. It's exactly this governance block that our compliance overlay wires to every design we produce — not a separate document, but the controls inside the flow.

We've turned the first step into a self-serve, free assessment: a few questions and an indication of where to start, with what controls around it. Take the AI-readiness assessment — and if the theme is the governance of a use case you're about to adopt, write to us and let's talk.

This article is for orientation and does not constitute legal advice. The regulatory framework on the AI Act, GDPR and Italian law is evolving — in particular deadlines, the scope of the DPIA and the Garante's guidance may change: they must be verified against the text in force for the specific case of the individual company.