Validare gli output dei LLM: un framework quantitativo per data team e workflow aziendali

Come smettere di chiedersi “Mi fido?” e iniziare a misurare il rischio dell’AI

Un framework quantitativo in Python per decidere quanto controllo umano applicare agli output di LLM e modelli AI

Ti è mai capitato di fare copia-incolla di un prompt per generare una query SQL complessa, un’analisi di marketing o una previsione, guardare il risultato e chiederti:

“Mi fido oppure devo controllare tutto riga per riga?”

È una delle domande più frequenti quando l’intelligenza artificiale entra nei workflow professionali.

Ma è anche una domanda formulata male.

Il problema non è stabilire se possiamo fidarci dell’AI in assoluto.

Un LLM può generare una query SQL perfettamente corretta per un task e una query semanticamente sbagliata per un altro. Può produrre un riassunto utile per una riunione interna e una conclusione inaccettabile se utilizzata per prendere una decisione finanziaria. Può assistere un Data Analyst nella costruzione di un modello e, allo stesso tempo, non essere autorizzato a modificare automaticamente una campagna pubblicitaria.

La domanda corretta è quindi:

Quanto controllo umano dobbiamo applicare a questo specifico output AI, dato il task, il contesto e ciò che succederà dopo?

Questa distinzione cambia completamente il problema.

Invece di scegliere tra:

• fiducia totale;
• controllo totale;

possiamo costruire un framework quantitativo di supporto alla decisione.

L’obiettivo di questo articolo è proprio questo: trasformare una valutazione qualitativa del rischio in uno score operativo da 0 a 10, collegato a tre possibili livelli di supervisione:

• 🟢 Verifica rapida
• 🟡 Audit metodologico
• 🔴 Human-in-the-loop / blocco umano

Non stiamo costruendo una probabilità di errore dell’AI.

Stiamo costruendo qualcosa di diverso e, in un contesto aziendale, molto utile:

un criterio strutturato per decidere quanto deve essere rigorosa la verifica prima che un output AI possa entrare nel processo decisionale.

👉 Differenza tra AI Tool Literacy e AI Epistemic Literacy: come verificare le risposte dell’intelligenza artificiale

---

Perché “l’AI può sbagliare” non è una policy

Dire che un LLM può sbagliare è vero, ma non è sufficiente per governare un processo.

Immaginiamo due output prodotti dallo stesso modello.

Task A

L’AI genera una bozza di SQL utilizzata da un Data Analyst per esplorare velocemente un dataset.

Se la query è sbagliata:

• il risultato può essere verificato;
• l’analista può correggerlo;
• nessuna decisione viene eseguita automaticamente.

Task B

Lo stesso sistema genera una regola che modifica automaticamente il budget giornaliero delle campagne pubblicitarie.

Se la logica è sbagliata:

• il budget può essere allocato male;
• l’errore può propagarsi rapidamente;
• l’organizzazione può subire una perdita economica;
• l’errore potrebbe non essere immediatamente visibile.

Il modello AI è lo stesso.

Il rischio non è lo stesso.

Possiamo quindi rappresentare il problema come:

[math]\boxed{ \text{Rischio operativo} = f(\text{AI},\text{task},\text{contesto},\text{azione downstream}) }[/math]

Questo è il principio alla base del framework.

---

Dal giudizio qualitativo a uno score

Per costruire un indice semplice da utilizzare in azienda introduciamo quattro variabili, tutte comprese tra 0 e 10.

1. Impatto dell’errore — [math]I[/math]

Misura quanto sarebbe grave una decisione sbagliata.

Consideriamo, per esempio:

• perdita economica;
• danno reputazionale;
• rischio operativo;
• conseguenze legali;
• impatto sui clienti;
• impatto sulla sicurezza.

Una possibile scala:

Punteggio	Interpretazione
0–2	Errore facilmente reversibile, conseguenze trascurabili
3–4	Conseguenze limitate
5–6	Conseguenze operative o economiche significative
7–8	Conseguenze elevate
9–10	Conseguenze critiche o difficilmente reversibili

Il punto importante è che non stiamo stimando la probabilità che l’AI sbagli.

Stiamo stimando quanto costa sbagliare.

---

2. Volatilità del dominio — [math]V[/math]

Misura quanto rapidamente cambia il contesto nel quale opera il sistema.

Un processo amministrativo stabile può avere volatilità bassa.

Un sistema che opera su:

• mercati finanziari;
• advertising;
• prezzi;
• domanda;
• supply chain;
• comportamenti degli utenti;

può avere volatilità maggiore.

La volatilità è importante perché un modello costruito su determinate condizioni può diventare meno appropriato quando cambiano dati, comportamenti o relazioni tra variabili.

Non significa che un dominio volatile renda automaticamente un modello inaffidabile.

Significa che aumenta la necessità di verificare che le assunzioni continuino a essere valide.

---

3. Complessità del task — [math]C[/math]

Misura quanto è difficile verificare correttamente l’output.

La complessità aumenta quando entrano in gioco:

• causalità;
• forecasting;
• inferenza statistica;
• ottimizzazione;
• molte variabili interdipendenti;
• modelli statistici complessi;
• trasformazioni multiple dei dati;
• decisioni basate su assunzioni non immediatamente visibili.

Una semplice query descrittiva può essere relativamente facile da controllare.

Una pipeline che costruisce una previsione della domanda e determina automaticamente il livello di stock è molto più complessa.

---

4. Verificabilità — [math]T[/math]

Nella versione iniziale del framework avevamo utilizzato il termine “trasparenza”.

È più preciso parlare di verificabilità.

La domanda non è semplicemente:

“Quanto è trasparente il modello?”

ma:

“Quanto facilmente un essere umano competente può controllare se l’output è corretto?”

Un output può essere altamente verificabile quando:

• il codice è leggibile;
• i dati utilizzati sono tracciabili;
• le trasformazioni sono documentate;
• le assunzioni sono esplicite;
• è possibile riprodurre il risultato;
• esistono test automatici;
• esistono controlli di qualità.

La verificabilità non garantisce la correttezza.

Un SQL perfettamente leggibile può comunque implementare una logica di business sbagliata.

Ma un output più verificabile può ridurre il costo e il tempo necessari per effettuare il controllo.

Ed è questo che ci interessa.

---

La formula

Definiamo:

[math]I = \text{Impatto dell’errore}[/math]
[math]V = \text{Volatilità del dominio}[/math]
[math]C = \text{Complessità del task}[/math]
[math]T = \text{Verificabilità}[/math]

Costruiamo quindi il punteggio grezzo:

[math]\boxed{ S_{raw} = 0.35I + 0.25V + 0.25C – 0.15T }[/math]

L’interpretazione è semplice:

• l’impatto pesa per il 35%;
• volatilità e complessità pesano ciascuna per il 25%;
• la verificabilità agisce come fattore attenuante, con peso −15%.

Il peso maggiore viene assegnato all’impatto perché, dal punto di vista manageriale, la gravità della conseguenza deve avere più peso della difficoltà tecnica del task.

---

Ma attenzione: questi pesi non sono “verità statistiche”

Questa precisazione è fondamentale.

I coefficienti:

[math]0.35,\quad 0.25,\quad 0.25,\quad -0.15[/math]

non sono stati stimati attraverso un dataset di incidenti AI.

Non derivano da una regressione.

Non sono coefficienti universalmente validi.

Sono parametri progettuali.

Il framework è quindi un’euristica quantitativa: serve a rendere esplicita, coerente e ripetibile una valutazione che altrimenti rimarrebbe completamente soggettiva.

Questo significa che un’azienda può decidere di utilizzare pesi diversi.

Per esempio, in un ambiente estremamente regolamentato potrebbe attribuire maggiore peso all’impatto dell’errore.

Il valore del framework non sta quindi nel sostenere:

“0.35 è il peso corretto”.

Sta nel costringere l’organizzazione a rispondere in modo esplicito a quattro domande:

1. Quanto è grave sbagliare?
2. Quanto è instabile il contesto?
3. Quanto è difficile verificare il task?
4. Quanto è facilmente verificabile l’output?

---

Normalizziamo lo score

Poiché i tre fattori positivi possono assumere valori compresi tra 0 e 10, il massimo contributo positivo è:

[math]0.35(10) + 0.25(10) + 0.25(10) = 8.5[/math]

Per riportare lo score su una scala intuitiva 0–10 utilizziamo:

[math]S = 10 \cdot \frac{S_{raw}}{8.5}[/math]

e applichiamo infine un limite:

[math]\boxed{ S = \operatorname{clip}\left(10 \cdot \frac{S_{raw}}{8.5}, 0, 10\right) }[/math]

Il clipping è importante perché, nei casi estremi, il contributo negativo della verificabilità può rendere [math]S_{raw}[/math] negativo.

Per esempio, con:

[math]I = V = C = 0,\qquad T = 10[/math]

otteniamo:

[math]S_{raw} = -1.5[/math]

Il sistema riporta quindi lo score operativo a 0.

---

Uno score di 8 NON significa “80% di probabilità di errore”

Questo punto va sottolineato.

Lo score non è una probabilità.

Se:

[math]S = 8[/math]

non significa:

[math]P(\text{errore}) = 0.8[/math]

e non significa nemmeno che un task con score 8 sia “due volte più rischioso” di uno con score 4.

Lo score è un indice decisionale.

Serve a stabilire il livello di supervisione.

Quindi:

[math]\boxed{ \text{Score} \neq \text{Probabilità di errore} }[/math]

e:

[math]\boxed{ \text{Score} \rightarrow \text{Policy di verifica} }[/math]

---

Dal numero all’azione

Uno score è utile soltanto se produce una decisione.

Proponiamo tre fasce operative:

Score	Livello	Cosa facciamo
[math]S < 3.5[/math]	🟢 Verifica rapida	Spot-check
[math]3.5 \le S \le 6.5[/math]	🟡 Audit metodologico	Revisione strutturata
[math]S > 6.5[/math]	🔴 Human-in-the-loop	Decisione finale umana obbligatoria

Le soglie non sono universali.

Sono soglie di policy.

Un’organizzazione più prudente potrebbe abbassare la soglia del blocco umano.

Il punto non è quindi trovare la soglia “scientificamente corretta”.

Il punto è rendere esplicita la regola:

quando il punteggio supera una determinata soglia, cambia il processo di approvazione.

---

Implementiamo il framework in Python

Possiamo tradurre il modello in poche righe.

def verification_score(
    impact_error,
    volatility,
    task_complexity,
    verifiability
):
    """
    Calcola uno score euristico di supervisione AI
    su scala 0-10.

    I quattro input devono essere compresi
    tra 0 e 10.
    """

    values = [
        impact_error,
        volatility,
        task_complexity,
        verifiability
    ]

    if not all(0 <= value <= 10 for value in values):
        raise ValueError(
            "Tutti i parametri devono essere compresi tra 0 e 10."
        )

    raw_score = (
        0.35 * impact_error
        + 0.25 * volatility
        + 0.25 * task_complexity
        - 0.15 * verifiability
    )

    score = (raw_score / 8.5) * 10

    # Limitiamo lo score all'intervallo [0, 10]
    score = max(0, min(10, score))

    return round(score, 2)

La classificazione può essere separata dalla funzione matematica:

def classify_verification(score):

    if score < 3.5:
        return "Verifica rapida"

    elif score <= 6.5:
        return "Audit metodologico"

    else:
        return "Human-in-the-loop"

Infine possiamo creare una funzione che unisce le due operazioni:

def verification_framework(
    impact_error,
    volatility,
    task_complexity,
    verifiability
):

    score = verification_score(
        impact_error,
        volatility,
        task_complexity,
        verifiability
    )

    level = classify_verification(score)

    return score, level

---

Prima applicazione: un’analisi di marketing

Supponiamo che un sistema AI analizzi le campagne pubblicitarie e suggerisca dove aumentare il budget.

Attribuiamo:

[math]I = 6[/math]
[math]V = 6[/math]
[math]C = 7[/math]
[math]T = 5[/math]

Il codice è:

score, level = verification_framework(
    impact_error=6,
    volatility=6,
    task_complexity=7,
    verifiability=5
)

print(f"Score: {score}")
print(f"Livello: {level}")

Output

Score: 5.41
Livello: Audit metodologico

Come interpretiamo il risultato?

Matematicamente:

[math]\displaystyle \begin{aligned}
S_{raw} & = 0.35(6) + 0.25(6) + 0.25(7) – 0.15(5) \\
& = 2.10 + 1.50 + 1.75 – 0.75 \\
& = 4.60
\end{aligned}[/math]

Normalizziamo:

[math]S = \frac{4.60}{8.5} \times 10[/math]
[math]\boxed{S = 5.41}[/math]

Il valore si trova nell’intervallo:

[math]3.5 \le S \le 6.5[/math]

quindi:

[math]\boxed{\text{Audit metodologico}}[/math]

---

Ma cosa significa concretamente “Audit metodologico”?

Questa è la domanda più importante.

Non significa:

“Controlliamo che il Python funzioni.”

Significa controllare se il risultato abbia senso dal punto di vista statistico e di business.

Per un’analisi di marketing controlleremmo almeno:

1. Definizione della conversione

Che cosa significa esattamente “conversione”?

Una vendita?

Un lead?

Una registrazione?

Un acquisto attribuito?

Se la definizione cambia, cambia il KPI.

2. Finestra temporale

Quale periodo stiamo analizzando?

La finestra è coerente con il ciclo di acquisto?

3. Attribuzione

La conversione viene attribuita correttamente ai touchpoint?

4. Confondenti

Una campagna apparentemente performante potrebbe essere associata a un segmento che sarebbe comunque più propenso all’acquisto.

Correlazione e causalità non sono la stessa cosa.

5. Leakage

Stiamo utilizzando informazioni che non sarebbero state disponibili al momento della previsione?

6. Look-ahead bias

Stiamo involontariamente utilizzando informazioni future nella valutazione?

7. Periodo di training

Il periodo utilizzato dal modello è coerente con quello sul quale viene applicato?

8. Robustezza

La conclusione rimane valida se cambiamo:

• finestra temporale;
• segmentazione;
• modello;
• assunzioni;
• campione?

9. Business meaning

Anche se il modello è statisticamente corretto, la decisione suggerita ha senso economicamente?

Questa è la parte che un LLM non dovrebbe automaticamente “autorizzarsi” a decidere.

---

Un caso più realistico: marketing mart in dbt

Immaginiamo ora un caso molto più vicino a un workflow Data Engineering.

La pipeline è:

raw_events
     ↓
stg_campaign_events
     ↓
int_campaign_metrics
     ↓
fct_marketing_performance
     ↓
dashboard / decisioni di budget

Un LLM viene utilizzato per generare o modificare il codice SQL del modello finale.

{{ config(materialized='table') }}

select
    campaign_id,
    date,
    sum(conversions) as conversions,
    sum(spend) as spend,
    sum(revenue) as revenue
from {{ ref('stg_campaign_events') }}
group by
    campaign_id,
    date

A prima vista il codice è semplice.

Ed è proprio questo il problema.

Sintatticamente semplice non significa semanticamente sicuro.

---

Valutiamo il task

Assegniamo:

[math]I = 7[/math]

perché il mart alimenta decisioni di allocazione del budget.

[math]V = 7[/math]

perché le piattaforme advertising, i dati e le modalità di tracking possono cambiare.

[math]C = 7[/math]

perché entrano in gioco attribuzione, join, deduplicazione e definizioni dei KPI.

Infine:

[math]T = 5[/math]

perché il codice SQL è leggibile, ma la logica di business sottostante non è necessariamente immediatamente verificabile.

Il codice Python:

score, level = verification_framework(
    impact_error=7,
    volatility=7,
    task_complexity=7,
    verifiability=5
)

print(f"Score: {score}")
print(f"Livello: {level}")

produce:

Score: 6.12
Livello: Audit metodologico

---

Analizziamo matematicamente il risultato

Il punteggio grezzo è:

[math]\displaystyle \begin{aligned}
S_{raw} & = 0.35(7) + 0.25(7) + 0.25(7) – 0.15(5) \\
& = 2.45 + 1.75 + 1.75 – 0.75 \\
& = 5.20
\end{aligned}[/math]

Normalizziamo:

[math]S = \frac{5.20}{8.5} \times 10[/math]

ottenendo:

[math]\boxed{S = 6.12}[/math]

Poiché:

[math]3.5 \le 6.12 \le 6.5[/math]

la classificazione è:

[math]\boxed{\text{Audit metodologico}}[/math]

---

Managerialmente: cosa facciamo con 6,12?

Qui il numero diventa interessante.

Non blocchiamo automaticamente la pipeline.

Ma non permettiamo nemmeno che l’output dell’AI venga utilizzato senza revisione.

La regola operativa potrebbe essere:

L’AI può proporre il codice. Il codice può essere eseguito in ambiente di test. La promozione in produzione richiede una revisione metodologica umana.

Il Data Engineer non deve quindi controllare soltanto:

“La query gira?”

Deve chiedersi:

“La query calcola esattamente ciò che il business intende misurare?”

---

Dove può nascondersi l’errore?

Deduplicazione

Se un utente genera più eventi associati alla stessa conversione, una semplice:

sum(conversions)

potrebbe produrre una metrica gonfiata.

Questo è un problema di conteggio o modellazione degli eventi, non automaticamente di leakage.

---

Leakage

La domanda corretta è invece:

Stiamo utilizzando, nella costruzione di una previsione o di un modello, informazioni che al momento della previsione non sarebbero state disponibili?

Questa è una questione diversa.

---

Temporalità

Bisogna inoltre verificare quale data rappresenti il record:

• data del click;
• data dell’impression;
• data della conversione;
• data dell’ordine;
• data dell’incasso.

Una scelta apparentemente banale può modificare completamente il significato della metrica.

---

Revenue

Anche:

sum(revenue)

richiede una definizione.

Stiamo considerando:

• ricavi lordi?
• ricavi netti?
• resi?
• cancellazioni?
• sconti?

Una metrica tecnicamente corretta può quindi essere business-wise sbagliata.

---

Il principio manageriale fondamentale

Questo è uno dei motivi per cui la supervisione degli output AI non può essere affidata soltanto al controllo sintattico.

Un LLM può produrre:

SELECT ...

perfettamente valido.

Il database può eseguirlo.

I test tecnici possono passare.

E il risultato può comunque essere sbagliato dal punto di vista del business.

Per questo:

[math]\boxed{ \text{Validità sintattica} \neq \text{Validità semantica} \neq \text{Validità decisionale} }[/math]

Sono tre livelli differenti.

---

E se l’impatto aumenta?

Supponiamo che la stessa pipeline non alimenti più soltanto una dashboard.

Supponiamo invece che il suo output venga utilizzato da un sistema di Reverse ETL per modificare automaticamente il bidding su una piattaforma advertising.

Il task è praticamente lo stesso.

Ma l’impatto cambia.

Portiamo:

[math]I: 7 \rightarrow 9[/math]

mantenendo:

[math]V = 7,\quad C = 7,\quad T = 5[/math]

Il codice Python produce:

Score: 6.94
Livello: Human-in-the-loop

Matematicamente:

[math]\displaystyle \begin{aligned}
S_{raw} & = 0.35(9) + 0.25(7) + 0.25(7) – 0.15(5) \\
& = 3.15 + 1.75 + 1.75 – 0.75 \\
& = 5.90
\end{aligned}[/math]

quindi:

[math]S = \frac{5.90}{8.5} \times 10[/math]
[math]\boxed{S = 6.94}[/math]

Superiamo la soglia di 6.5.

---

La tecnologia è la stessa. La policy cambia.

Questo è probabilmente il risultato manageriale più importante dell’intero framework.

Nel primo caso:

AI → SQL → dashboard → analista

abbiamo:

[math]S = 6.12[/math]

e quindi:

🟡 Audit metodologico

Nel secondo caso:

AI → SQL → sistema automatico → modifica budget

abbiamo:

[math]S = 6.94[/math]

e quindi:

🔴 Human-in-the-loop

Non abbiamo cambiato necessariamente:

• LLM;
• algoritmo;
• query;
• dataset.

Abbiamo cambiato ciò che succede dopo l’output.

Ed è sufficiente per cambiare il livello di governance.

---

Cosa significa davvero “Human-in-the-loop”?

Non significa necessariamente che una persona debba controllare manualmente ogni riga di SQL.

Significa che:

l’AI non ha autorità finale sulla decisione ad alto impatto.

Per esempio:

AI genera raccomandazione
        ↓
controlli automatici
        ↓
validazione umana
        ↓
approvazione
        ↓
esecuzione

Possiamo automatizzare moltissimo.

Ma il passaggio:

[math]\boxed{ \text{Raccomandazione} \rightarrow \text{Decisione} }[/math]

rimane soggetto ad approvazione.

Questo è molto diverso dal bloccare l’uso dell’AI.

---

Sensitivity analysis: quanto è stabile la decisione?

Uno score non dovrebbe essere interpretato senza analizzare la sua sensibilità.

Consideriamo nuovamente il caso dbt:

[math]V = 7,\quad C = 7,\quad T = 5[/math]

e facciamo variare soltanto [math]I[/math].

import pandas as pd
import matplotlib.pyplot as plt

impact_values = range(0, 11)

scores = []

for impact in impact_values:

    score = verification_score(
        impact_error=impact,
        volatility=7,
        task_complexity=7,
        verifiability=5
    )

    scores.append(score)

sensitivity = pd.DataFrame({
    "impact_error": impact_values,
    "score": scores
})

print(sensitivity)

L’output numerico è:

    impact_error  score
0              0   3.41
1              1   3.82
2              2   4.24
3              3   4.65
4              4   5.06
5              5   5.47
6              6   5.88
7              7   6.12
8              8   6.53
9              9   6.94
10            10   7.35

Possiamo visualizzarlo:

plt.figure(figsize=(9, 5))

plt.plot(
    sensitivity["impact_error"],
    sensitivity["score"],
    marker="o"
)

plt.axhline(
    6.5,
    linestyle="--",
    label="Soglia human-in-the-loop"
)

plt.axhline(
    3.5,
    linestyle="--",
    label="Soglia audit metodologico"
)

plt.xlabel("Impatto dell'errore")
plt.ylabel("Score")
plt.title("Sensitivity analysis dello score")
plt.legend()
plt.grid(alpha=0.3)
plt.tight_layout()
plt.show()

---

Cosa ci dice il risultato?

La cosa interessante non è semplicemente che lo score aumenta.

È quanto rapidamente cambia la decisione.

Passiamo da:

[math]I = 7 \Rightarrow S = 6.12[/math]

a:

[math]I = 8 \Rightarrow S = 6.53[/math]

Quindi un solo punto nella valutazione dell’impatto è sufficiente per superare la soglia di human-in-the-loop.

Questo è un risultato manageriale importante.

Significa che il caso non dovrebbe essere trattato come:

“Lo score è 6,12, quindi la decisione è matematicamente stabilita.”

La domanda corretta è:

“Siamo sicuri che l’impatto sia davvero 7 e non 8?”

---

Lo score non elimina la soggettività: la rende visibile

Questo è uno dei limiti più importanti del framework.

I valori:

[math]I, V, C, T[/math]

sono valutazioni umane.

Quindi non abbiamo trasformato una valutazione soggettiva in una misura oggettiva.

Abbiamo trasformato una valutazione:

soggettiva e non strutturata

in una valutazione:

soggettiva, esplicita, documentabile e ripetibile.

Questa differenza è fondamentale.

Se due manager assegnano:

Manager A:
I = 7
V = 7
C = 7
T = 5

e:

Manager B:
I = 8
V = 7
C = 7
T = 5

otteniamo due decisioni diverse:

[math]S_A = 6.12[/math]
[math]S_B = 6.53[/math]

Il primo caso richiede audit metodologico.

Il secondo supera la soglia proposta per l’human-in-the-loop.

Questo non è necessariamente un difetto.

È un segnale.

Quando la valutazione di un singolo parametro può cambiare la policy, quel parametro deve essere discusso.

---

Come migliorare la valutazione manageriale

Invece di chiedere a una singola persona:

“Quanto è rischioso questo task?”

possiamo introdurre una piccola procedura di governance.

Step 1 — Valutazione

Il responsabile del processo assegna:

[math]I, V, C, T[/math]

Step 2 — Second opinion

Per task con score vicino a una soglia, un secondo stakeholder effettua una valutazione indipendente.

Step 3 — Sensitivity analysis

Se le valutazioni sono discordanti, calcoliamo lo score per entrambi gli scenari.

Step 4 — Policy conservativa

Se una variazione ragionevole porta il task nella fascia rossa, l’organizzazione può decidere di adottare temporaneamente il livello di controllo superiore.

In altre parole:

vicino a una soglia, non bisogna fidarsi ciecamente del numero. Bisogna analizzare l’incertezza della classificazione.

---

Possiamo estendere il framework a una heatmap

La sensitivity analysis precedente modifica un solo parametro.

Ma possiamo studiare contemporaneamente due dimensioni.

Per esempio:

[math]S(I, V)[/math]

mantenendo costanti:

[math]C = 7,\qquad T = 5[/math]

Possiamo generare una heatmap:

import numpy as np
import matplotlib.pyplot as plt

impact_values = np.arange(0, 11)
volatility_values = np.arange(0, 11)

score_matrix = np.zeros(
    (len(volatility_values), len(impact_values))
)

for i, volatility in enumerate(volatility_values):

    for j, impact in enumerate(impact_values):

        score_matrix[i, j] = verification_score(
            impact_error=impact,
            volatility=volatility,
            task_complexity=7,
            verifiability=5
        )

plt.figure(figsize=(9, 6))

plt.imshow(
    score_matrix,
    origin="lower",
    aspect="auto",
    extent=[0, 10, 0, 10]
)

plt.colorbar(label="Score")

plt.contour(
    impact_values,
    volatility_values,
    score_matrix,
    levels=[3.5, 6.5],
    linestyles="--"
)

plt.xlabel("Impatto dell'errore")
plt.ylabel("Volatilità del dominio")
plt.title(
    "Mappa del livello di supervisione "
    "(C=7, T=5)"
)

plt.tight_layout()
plt.show()

La heatmap permette di visualizzare immediatamente le zone nelle quali il processo passa da:

🟢 verifica rapida

a

🟡 audit metodologico

fino a

🔴 human-in-the-loop.

Questo è molto più utile, in una dashboard manageriale, di un singolo numero.

---

Come trasformare il framework in una policy aziendale

A questo punto possiamo fare il salto dalla data science alla governance.

Una possibile policy è:

🟢 Score < 3.5

L’AI può essere utilizzata con supervisione leggera.

Esempi:

• brainstorming;
• query esplorative;
• documentazione;
• trasformazioni non critiche;
• analisi preliminari.

Azione manageriale:

Consentire l’utilizzo dell’AI con spot-check.

🟡 Score 3.5–6.5

L’AI può produrre l’output, ma serve una revisione metodologica.

Esempi:

• dashboard decisionali;
• modelli di forecasting;
• analisi marketing;
• pipeline dati;
• segmentazioni;
• analisi statistiche.

Azione manageriale:

Consentire l’uso dell’AI, ma richiedere approvazione del responsabile tecnico o di dominio prima della produzione.

🔴 Score > 6.5

L’AI può assistere, ma non può avere autorità finale.

Esempi:

• decisioni finanziarie automatiche;
• modifica automatica del budget;
• decisioni ad alto impatto sui clienti;
• processi regolamentati;
• automazioni difficilmente reversibili.

Azione manageriale:

Introdurre obbligatoriamente un human-in-the-loop.

---

Il vero punto: non automatizzare la decisione, automatizzare il controllo

Questa distinzione è fondamentale.

Un’organizzazione non deve necessariamente scegliere tra:

“AI autonoma”

e:

“AI vietata”.

Esiste una terza possibilità:

[math]\boxed{ \text{Automazione proporzionata al rischio} }[/math]

Possiamo automatizzare:

• generazione del codice;
• controlli sintattici;
• test;
• data quality;
• validazioni;
• logging;
• monitoraggio;
• calcolo dello score.

E possiamo riservare all’essere umano soltanto il passaggio decisionale nei casi più rischiosi.

---

Un possibile workflow operativo

Il framework può diventare un vero AI risk gate:

                 TASK AI
                    │
                    ▼
          ┌───────────────────┐
          │ Valutazione I,V,C,T│
          └─────────┬─────────┘
                    │
                    ▼
              SCORE 0–10
                    │
          ┌─────────┼─────────┐
          │         │         │
          ▼         ▼         ▼
       < 3.5     3.5–6.5    > 6.5
          │         │         │
          ▼         ▼         ▼
       Spot       Audit      Human
       check    metodologico  approval
          │         │         │
          └─────────┼─────────┘
                    ▼
              PRODUZIONE

Questo è il vero valore del framework.

Non serve per decidere se l’AI sia buona o cattiva.

Serve per decidere:

quanto deve essere difficile per un output AI arrivare in produzione.

---

Dal punto di vista Data Science: cosa stiamo realmente modellando?

È importante essere precisi.

Non stiamo stimando:

[math]P(\text{errore AI})[/math]

e non stiamo stimando:

[math]P(\text{decisione sbagliata})[/math]

Stiamo costruendo una funzione:

[math]S = f(I, V, C, T)[/math]

che associa a una configurazione qualitativa un livello quantitativo di supervisione.

Quindi il framework è più vicino a una:

decision rule

che a un:

predictive model.

Questa distinzione evita di attribuire allo score proprietà statistiche che non possiede.

---

E i pesi possono essere calibrati?

Sì.

Questa potrebbe essere una seconda fase del progetto.

Se un’organizzazione dispone di uno storico di:

• incidenti;
• errori;
• escalation;
• revisioni;
• costi degli errori;
• falsi positivi;
• falsi negativi;

può cercare di calibrare empiricamente i parametri.

Per esempio, si potrebbe osservare se determinati livelli di:

[math]I, V, C, T[/math]

sono associati a una maggiore frequenza di incidenti.

A quel punto il framework potrebbe evolvere da:

[math]\boxed{\text{euristica}}[/math]

a:

[math]\boxed{\text{modello empiricamente calibrato}}[/math]

Ma sono due livelli diversi.

Il framework presentato in questo articolo è il punto di partenza, non il punto di arrivo.

---

Un’altra evoluzione: separare rischio e verificabilità

Una possibile evoluzione metodologica consiste nel non incorporare la verificabilità direttamente nello score.

Potremmo infatti distinguere:

[math]R = f(I, V, C)[/math]

dal costo di verifica:

[math]K = f(T)[/math]

In questo modo avremmo due domande diverse:

Quanto è rischioso il task?

e:

Quanto costa verificarlo?

Questa estensione potrebbe essere particolarmente interessante in un’organizzazione che deve ottimizzare le proprie risorse di Data Engineering e Data Governance.

Un task potrebbe essere:

• molto rischioso;
• ma facilmente verificabile.

Oppure:

• moderatamente rischioso;
• ma estremamente costoso da verificare.

Le due situazioni richiedono strategie diverse.

---

Cosa dovrebbe fare un manager davanti a uno score?

Supponiamo di avere:

[math]S = 6.12[/math]

La domanda non dovrebbe essere:

“Quindi possiamo fidarci al 61,2%?”

La risposta è ovviamente no.

La domanda corretta è:

“Quale controllo aggiuntivo dobbiamo introdurre prima di consentire a questo output di produrre effetti?”

Nel caso dbt, la risposta potrebbe essere:

Prima della produzione

1. Code review.
2. Test di unicità.
3. Test sui valori null.
4. Controllo delle join.
5. Verifica della definizione delle conversioni.
6. Controllo della finestra temporale.
7. Confronto con una versione precedente del mart.
8. Validazione di KPI su un campione noto.
9. Approvazione del Data Owner.
10. Monitoraggio dopo il rilascio.

Questa è la vera trasformazione:

[math]\boxed{ \text{Score} \rightarrow \text{Controlli} \rightarrow \text{Decisione} }[/math]

---

E se lo score è 6,94?

Qui la policy cambia.

Non significa:

“L’AI è pericolosa.”

Significa:

“Il costo potenziale di un errore è abbastanza elevato da non permettere all’AI di avere l’ultima parola.”

Quindi:

• AI genera;
• AI propone;
• AI accelera;
• AI analizza;
• AI simula;

ma:

[math]\boxed{\text{l’essere umano approva}}[/math]

prima dell’azione irreversibile o ad alto impatto.

---

Il vero obiettivo: calibrare la fiducia

Il framework serve a evitare due errori opposti.

Errore 1 — Fiducia eccessiva

“Il modello ha prodotto un risultato convincente, quindi possiamo utilizzarlo.”

La qualità linguistica di un output non è una misura della sua correttezza.

Errore 2 — Diffidenza indiscriminata

“L’AI può sbagliare, quindi dobbiamo controllare manualmente tutto.”

Questo elimina gran parte del vantaggio dell’automazione.

La soluzione

[math]\boxed{ \text{Livello di verifica} \propto \text{rischio della decisione} }[/math]

Non dobbiamo verificare tutto allo stesso modo.

Dobbiamo concentrare le risorse di verifica dove il costo dell’errore è maggiore.

---

Prova il framework sul tuo prossimo task AI

Puoi iniziare anche senza costruire una piattaforma di AI governance.

Prendi l’ultimo task che hai delegato a un LLM.

Assegna:

impact_error = ?
volatility = ?
task_complexity = ?
verifiability = ?

Poi calcola:

score, level = verification_framework(
    impact_error,
    volatility,
    task_complexity,
    verifiability
)

print(f"Score: {score}")
print(f"Livello: {level}")

E interpreta il risultato.

🟢 Meno di 3.5

Può essere sufficiente uno spot-check.

🟡 Tra 3.5 e 6.5

Serve un audit metodologico.

Controlla:

• dati;
• assunzioni;
• bias;
• temporalità;
• leakage;
• metodologia statistica;
• definizione dei KPI;
• interpretazione;
• coerenza con il business.

🔴 Oltre 6.5

Il task è candidato all’human-in-the-loop.

L’AI può continuare a generare analisi, codice e scenari, ma la decisione finale rimane umana.

---

Limiti del framework

Un buon modello decisionale deve dichiarare anche ciò che non sa fare.

Questo framework:

• non misura la probabilità di errore dell’AI;
• non garantisce che un output con score basso sia corretto;
• non sostituisce una valutazione normativa o legale;
• non sostituisce il risk assessment aziendale;
• utilizza input in parte soggettivi;
• utilizza pesi scelti progettualmente;
• utilizza soglie che devono essere adattate al contesto.

Il suo valore è diverso.

Rende il processo:

• più esplicito;
• più documentabile;
• più ripetibile;
• più discutibile;
• più facilmente integrabile nei workflow.

E soprattutto rende visibile perché una decisione richiede un determinato livello di supervisione.

---

Da una formula a un sistema di governance

La formula:

[math]\boxed{ S = \operatorname{clip}\left( \frac{0.35I + 0.25V + 0.25C – 0.15T}{8.5} \times 10, 0, 10 \right) }[/math]

non è, da sola, un sistema di AI governance.

Diventa governance quando viene collegata a una policy:

[math]\boxed{ \text{Score} \rightarrow \text{Livello di controllo} \rightarrow \text{Responsabile} \rightarrow \text{Approvazione} \rightarrow \text{Produzione} }[/math]

A quel punto può essere integrata, per esempio, in:

• ticket di sviluppo;
• workflow di approvazione;
• pipeline CI/CD;
• dashboard di AI governance;
• processi di model review;
• sistemi di audit;
• pipeline dati;
• workflow di deployment.

Il framework può quindi diventare un gate di rischio.

Non blocca automaticamente l’automazione.

La rende proporzionata al rischio.

---

Conclusione

Il problema dell’AI nei workflow professionali non è soltanto:

“Quanto è brava l’intelligenza artificiale?”

La domanda più importante è:

“Quanto deve essere difficile per questo output AI diventare una decisione?”

Una query SQL generata per esplorare un dataset e una query SQL che alimenta un sistema automatico di bidding possono essere prodotte dallo stesso modello.

Non devono però avere necessariamente lo stesso livello di supervisione.

Nel primo caso possiamo accettare:

[math]\text{AI} \rightarrow \text{output} \rightarrow \text{spot-check}[/math]

Nel secondo:

[math]\text{AI} \rightarrow \text{output} \rightarrow \text{controlli} \rightarrow \text{approvazione umana}[/math]

Il framework proposto rende questa differenza esplicita attraverso quattro dimensioni:

[math]I = \text{Impatto}[/math]
[math]V = \text{Volatilità}[/math]
[math]C = \text{Complessità}[/math]
[math]T = \text{Verificabilità}[/math]

e le combina in uno score operativo.

Ma il numero non è il risultato finale.

Il vero risultato è la decisione che il numero rende possibile.

Se otteniamo:

[math]S = 3.2[/math]

possiamo probabilmente permettere un’automazione con controllo leggero.

Se otteniamo:

[math]S = 6.12[/math]

dobbiamo fermarci a un audit metodologico prima di trasformare l’output in una decisione.

Se otteniamo:

[math]S = 6.94[/math]

la policy può richiedere obbligatoriamente un essere umano nel circuito decisionale.

E questa è forse la lezione più importante:

[math]\boxed{ \text{Non dobbiamo decidere se fidarci dell’AI.} }[/math]
[math]\boxed{ \text{Dobbiamo decidere quanto controllo merita ogni suo output.} }[/math]

La vera AI literacy, per chi lavora con i dati, non consiste quindi soltanto nel sapere come ottenere una risposta da un modello.

Consiste nel sapere:

quando utilizzarla, come verificarla, quanto verificarla e chi deve avere l’ultima parola.

È qui che Data Science, AI literacy e AI governance iniziano realmente a convergere.