Risk Intelligence: quanto tempo abbiamo prima che la disruption diventi un problema economico?

Dal rischio tecnologico alla decisione del CFO

Immaginiamo un retailer che dipende fortemente dal traffico organico e dai canali digitali tradizionali.

Il management sa che il comportamento dei clienti sta cambiando.

Sempre più persone utilizzano strumenti di intelligenza artificiale per:

• cercare informazioni;
• confrontare prodotti;
• ottenere raccomandazioni;
• sintetizzare recensioni;
• decidere quali aziende prendere in considerazione.

Il problema non è necessariamente un improvviso crollo delle vendite.

La disruption può iniziare molto prima.

Per disruption tecnologica intendiamo un cambiamento indotto da una nuova tecnologia che modifica significativamente il modo in cui clienti, imprese e piattaforme si incontrano nel mercato, alterando la distribuzione del valore e potenzialmente il margine catturato dal business.

Nel caso dell’AI, la disruption può manifestarsi anche senza che il prodotto cambi: è sufficiente che cambi chi controlla il percorso attraverso cui il cliente scopre, valuta e acquista quel prodotto.

Per esempio:

Prima	Dopo la disruption
Google porta traffico al sito	L’agente AI può rispondere direttamente
Il sito presenta i prodotti	L’AI può selezionare e confrontare i prodotti
Il cliente visita il retailer	Il cliente può essere indirizzato direttamente a un marketplace
Il retailer controlla parte del journey	Una piattaforma può controllare il punto decisionale
Il retailer monetizza il traffico	Parte del valore può essere catturata dall’intermediario

Il cliente può continuare ad acquistare, ma cambiare il percorso con cui arriva alla decisione.

Una parte del processo informativo può spostarsi dal sito aziendale verso motori di ricerca, marketplace, assistenti AI o agenti software.

Per il management questo genera una difficoltà fondamentale.

Come si misura economicamente qualcosa che potrebbe diventare importante prima che il conto economico lo renda evidente?

La risposta proposta in questo articolo è costruire un sistema di Risk Intelligence capace di trasformare una fotografia statica del rischio in una traiettoria.

Il percorso è:

[math]\displaystyle \boxed{ Segnali \rightarrow JFI \rightarrow Bayes \rightarrow EML_t \rightarrow TTR \rightarrow NPV \rightarrow Decisione }[/math]

Il modello non pretende di prevedere il futuro.

Serve a rispondere a una domanda molto più concreta:

“Date le informazioni disponibili oggi, quanto rischio abbiamo, quanto velocemente sta crescendo e quanto vale economicamente intervenire prima?”

Il problema della fotografia statica

Nell’articolo “ Margine a rischio tecnologico: come misurare in euro l’esposizione di un business alla disruption AI”  abbiamo calcolato una metrica fondamentale: l’Expected Margin Loss.

Il nostro retailer sapeva che il suo Expected Margin Loss ([math]EML[/math]) era pari a €1,06 milioni, derivato da un’esposizione massima ([math]MME[/math]) di €5,88 milioni e da una probabilità di scenario del 18,1%.

Il CFO ha guardato il numero. Ha annuito. E poi ha fatto l’unica domanda che conta davvero:

“Questo numero è valido per quanto tempo?”

La verità è che il rischio tecnologico si comporta come l’interesse composto: si accumula in silenzio prima di esplodere sui bilanci.

La fotografia dell’esposizione economica scattata oggi sarà già obsoleta alla fine del trimestre.

Per passare da una misurazione passiva a una vera Risk Intelligence, dobbiamo smettere di calcolare il rischio in un singolo istante e iniziare a simularne la traiettoria.

Supponiamo che l’azienda abbia stimato un Margine Massimo Esposto (MME) pari a:

[math]MME = 5,88\ M€[/math]

e una probabilità iniziale di disruption:

[math]P(D) = 18,1\%[/math]

L’Expected Margin Loss è:

[math]EML = MME \times P(D)[/math]

quindi:

[math]EML = 5,88 \times 0,181[/math]

[math]\boxed{EML = 1,064\ M€}[/math]

Il dato sembra relativamente rassicurante.

La soglia di materialità stabilita dal management è, per esempio:

[math]S = 2\ M€[/math]

Poiché:

[math]1,064 < 2[/math]

il rischio è sotto la soglia.

Ma questa conclusione risponde soltanto alla domanda:

“Quanto rischio stimiamo oggi?”

Non risponde alla domanda più importante:

“Quanto rapidamente può cambiare questa esposizione?”

Se le condizioni di mercato cambiano, il 18,1% non può essere trattato come una costante.

È necessario aggiornare la valutazione.

Il Risk Intelligence System

Il sistema che costruiremo osserva il rischio trimestre dopo trimestre.

Per ogni periodo calcoliamo quattro elementi:

1. Journey Fragility Index (JFI);
2. probabilità aggiornata della disruption;
3. Expected Margin Loss (EML);
4. superamento o meno della soglia di materialità.

Infine utilizziamo la traiettoria dell’EML per valutare economicamente un intervento.

L’architettura è quindi:

Nuove evidenze
      │
      ▼
 Journey Fragility Index
      │
      ▼
 Aggiornamento Bayesiano
      │
      ▼
 Probabilità P(D|E)
      │
      ▼
 Expected Margin Loss
      │
      ▼
 Time-to-Risk
      │
      ▼
 Valutazione TOM
      │
      ▼
 NPV + Sensitivity Analysis

Il materiale di partenza utilizza esattamente questa logica, con una simulazione object-oriented che aggiorna progressivamente probabilità, JFI ed EML.

Journey Fragility Index: misurare la vulnerabilità del customer journey

Il primo indicatore è il Journey Fragility Index, o JFI.

L’idea è che una disruption tecnologica possa essere anticipata da cambiamenti nel comportamento del cliente.

Nel nostro esempio utilizziamo tre componenti:

• adozione dell’AI;
• calo del traffico organico;
• dipendenza da un canale.

Definiamo:

[math]JFI = 0,4AI + 0,4TrafficDecline + 0,2ChannelDependency[/math]

I pesi sommano a 1:

[math]0,4 + 0,4 + 0,2 = 1[/math]

Il valore è compreso tra 0 e 1.

Un JFI elevato indica maggiore fragilità.

Una precisazione importante

Il JFI non è una metrica standardizzata universalmente riconosciuta.

È un indice composito costruito per il caso studio.

I pesi 40%-40%-20% sono quindi ipotesi iniziali.

In un’azienda reale dovrebbero essere calibrati utilizzando:

• dati storici;
• analisi di sensitività;
• regressioni;
• giudizio esperto;
• capacità predittiva dei singoli segnali.

Il vantaggio del JFI non è quindi la presunta precisione assoluta.

È la possibilità di costruire un indicatore sintetico, aggiornabile e confrontabile nel tempo.

import pandas as pd

def sensitivity_prior(prior_values, dati_mercato, mme=5.88, soglia=2.00):
    """
    Esegue la simulazione bayesiana per una lista di valori prior (probabilità iniziali).

    Parametri:
    - prior_values: list di float, le probabilità iniziali da testare.
    - dati_mercato: list di dict, i dati trimestrali osservati.
    - mme: float, Margine Massimo Esposto in milioni di Euro.
    - soglia: float, limite di materialità oltre il quale il rischio richiede azione.

    Ritorna:
    - pd.DataFrame con il TTR e l'EML finale per ogni prior.
    """
    risultati = []

    for prior in prior_values:
        # Inizializziamo il sistema con il prior corrente
        sistema = RiskIntelligenceSystem(
            mme=mme,
            prob_iniziale=prior,
            soglia_materialita=soglia
        )

        # Iteriamo sui dati di mercato per aggiornare il rischio sequenzialmente
        for d in dati_mercato:
            sistema.simula_trimestre(
                trimestre=d["q"],
                p_e_dato_d=d["pe_d"],
                p_e_dato_non_d=d["pe_nd"],
                ai_adoption=d["ai"],
                calo_traffico=d["traffico"],
                dipendenza=d["dip"]
            )

        # Calcoliamo il Time-to-Risk e recuperiamo l'EML asintotico
        tt_risk = sistema.stima_time_to_risk()
        eml_finale = sistema.storia_trimestri[-1]["EML (€M)"]

        risultati.append({
            "Prior": f"{prior:.1%}",
            "Time-to-Risk": tt_risk,
            "EML finale (€M)": round(eml_finale, 3)
        })

    return pd.DataFrame(risultati)

# Esecuzione dell'analisi
prior_values = [0.02, 0.05, 0.10, 0.181, 0.30, 0.40, 0.50]
df_prior_sensitivity = sensitivity_prior(prior_values, dati_mercato)
print(df_prior_sensitivity)

Dalla probabilità alla perdita attesa

Una probabilità da sola non basta al CFO.

Il management vuole sapere:

“Quanto denaro è esposto?”

Utilizziamo quindi:

[math]EML_t = MME \times P(D_t|E_t)[/math]

Nel nostro caso:

[math]MME = 5,88M€[/math]

Nel Q1:

[math]EML_{Q1} = 5,88 \times 0,2789[/math]

[math]\boxed{EML_{Q1} = 1,640M€}[/math]

Nel Q2 la probabilità sale al 45,3%:

[math]EML_{Q2} = 5,88 \times 0,4532[/math]

[math]\boxed{EML_{Q2} = 2,665M€}[/math]

Ed ecco che il rischio supera la soglia di:

[math]2M€[/math]

Time-to-Risk: il rischio diventa una scadenza

Definiamo il Time-to-Risk come:

[math]TTR = \min\{t : EML_t \geq S\}[/math]

Nel nostro esempio:

[math]EML_{Q1} = 1,640M€[/math]

quindi:

[math]1,640 < 2[/math]

Nel Q2:

[math]EML_{Q2} = 2,665M€[/math]

quindi:

[math]2,665 > 2[/math]

Pertanto:

[math]\boxed{TTR = Q2}[/math]

Questo risultato è particolarmente importante.

Il rischio non diventa materialmente rilevante nel Q4.

Diventa rilevante già nel Q2.

Il materiale originale riportava infatti la stessa traiettoria Q1-Q6 e indicava Q2 come primo superamento della soglia.

La simulazione completa in Python

Ora costruiamo un modello riproducibile.

import pandas as pd
import numpy_financial as npf


class RiskIntelligenceSystem:

    def __init__(
        self,
        mme,
        prob_iniziale,
        soglia_materialita,
        tasso_sconto=0.08
    ):
        if mme < 0:
            raise ValueError("MME deve essere >= 0")

        if not 0 <= prob_iniziale <= 1:
            raise ValueError(
                "La probabilità iniziale deve essere "
                "compresa tra 0 e 1"
            )

        if soglia_materialita < 0:
            raise ValueError(
                "La soglia deve essere >= 0"
            )

        self.mme = mme
        self.prob_d = prob_iniziale
        self.soglia_materialita = soglia_materialita
        self.tasso_sconto = tasso_sconto

        self.storia_trimestri = []

    def aggiorna_probabilita_bayesiana(
        self,
        p_e_dato_d,
        p_e_dato_non_d
    ):
        """
        Aggiornamento bayesiano:

        P(D|E) =
        P(E|D)P(D) /
        [P(E|D)P(D) + P(E|~D)(1-P(D))]
        """

        if not 0 <= p_e_dato_d <= 1:
            raise ValueError(
                "P(E|D) deve essere tra 0 e 1"
            )

        if not 0 <= p_e_dato_non_d <= 1:
            raise ValueError(
                "P(E|~D) deve essere tra 0 e 1"
            )

        p_e = (
            p_e_dato_d * self.prob_d
            +
            p_e_dato_non_d * (1 - self.prob_d)
        )

        if p_e == 0:
            raise ValueError(
                "Probabilità dell'evidenza pari a zero"
            )

        self.prob_d = (
            p_e_dato_d * self.prob_d
        ) / p_e

        return self.prob_d

    def calcola_jfi(
        self,
        ai_adoption,
        calo_traffico,
        dipendenza_canale
    ):
        """
        JFI composito.

        I pesi sono ipotesi calibrabili.
        """

        valori = [
            ai_adoption,
            calo_traffico,
            dipendenza_canale
        ]

        if any(
            not 0 <= valore <= 1
            for valore in valori
        ):
            raise ValueError(
                "Le componenti del JFI devono "
                "essere tra 0 e 1"
            )

        peso_ai = 0.4
        peso_traffico = 0.4
        peso_dipendenza = 0.2

        jfi = (
            ai_adoption * peso_ai
            +
            calo_traffico * peso_traffico
            +
            dipendenza_canale * peso_dipendenza
        )

        return min(jfi, 1.0)

    def simula_trimestre(
        self,
        trimestre,
        p_e_dato_d,
        p_e_dato_non_d,
        ai_adoption,
        calo_traffico,
        dipendenza
    ):

        jfi = self.calcola_jfi(
            ai_adoption,
            calo_traffico,
            dipendenza
        )

        prob_aggiornata = (
            self.aggiorna_probabilita_bayesiana(
                p_e_dato_d,
                p_e_dato_non_d
            )
        )

        eml = self.mme * prob_aggiornata

        self.storia_trimestri.append({
            "Trimestre": trimestre,
            "JFI": round(jfi, 3),
            "P(D|E)": round(prob_aggiornata, 3),
            "EML (€M)": round(eml, 3),
            "Soglia Superata": (
                eml >= self.soglia_materialita
            )
        })

    def stima_time_to_risk(self):

        df = pd.DataFrame(
            self.storia_trimestri
        )

        critici = df[
            df["Soglia Superata"]
        ]

        if not critici.empty:
            return critici.iloc[0]["Trimestre"]

        return (
            "Soglia non raggiunta "
            "nella simulazione"
        )

I dati dello scenario

Utilizziamo sei trimestri.

MME = 5.88
PROB_INIZIALE = 0.181
SOGLIA = 2.00

sistema = RiskIntelligenceSystem(
    mme=MME,
    prob_iniziale=PROB_INIZIALE,
    soglia_materialita=SOGLIA
)


dati_mercato = [

    {
        "q": "Q1",
        "pe_d": 0.70,
        "pe_nd": 0.40,
        "ai": 0.15,
        "traffico": 0.05,
        "dip": 0.80
    },

    {
        "q": "Q2",
        "pe_d": 0.75,
        "pe_nd": 0.35,
        "ai": 0.20,
        "traffico": 0.08,
        "dip": 0.80
    },

    {
        "q": "Q3",
        "pe_d": 0.80,
        "pe_nd": 0.30,
        "ai": 0.28,
        "traffico": 0.12,
        "dip": 0.80
    },

    {
        "q": "Q4",
        "pe_d": 0.85,
        "pe_nd": 0.25,
        "ai": 0.35,
        "traffico": 0.18,
        "dip": 0.80
    },

    {
        "q": "Q5",
        "pe_d": 0.90,
        "pe_nd": 0.20,
        "ai": 0.45,
        "traffico": 0.25,
        "dip": 0.80
    },

    {
        "q": "Q6",
        "pe_d": 0.95,
        "pe_nd": 0.10,
        "ai": 0.55,
        "traffico": 0.35,
        "dip": 0.80
    }
]


for dato in dati_mercato:

    sistema.simula_trimestre(
        trimestre=dato["q"],
        p_e_dato_d=dato["pe_d"],
        p_e_dato_non_d=dato["pe_nd"],
        ai_adoption=dato["ai"],
        calo_traffico=dato["traffico"],
        dipendenza=dato["dip"]
    )


df_risultati = pd.DataFrame(
    sistema.storia_trimestri
)

print(
    df_risultati.to_string(index=False)
)

print(
    "\nTime-to-Risk:",
    sistema.stima_time_to_risk()
)

Output

L’esecuzione produce:

Trimestre   JFI  P(D|E)  EML (€M)  Soglia Superata
Q1        0.240   0.279     1.640             False
Q2        0.272   0.453     2.665              True
Q3        0.320   0.688     4.048              True
Q4        0.372   0.883     5.189              True
Q5        0.440   0.971     5.711              True
Q6        0.520   0.997     5.862              True

Time-to-Risk: Q2

Questi valori sono coerenti con il modello e con i dati dello scenario originale.

Come deve leggere questa tabella un CFO?

La prima informazione è il JFI.

Passa da:

[math]0,240[/math]

a:

[math]0,520[/math]

La fragilità del customer journey più che raddoppia.

Ma ancora più interessante è la probabilità.

[math]27,9\% \rightarrow 45,3\% \rightarrow 68,8\% \rightarrow 88,3\% \rightarrow 97,1\% \rightarrow 99,7\%[/math]

Il modello mostra quindi una forte accelerazione della plausibilità dello scenario.

L’EML segue la stessa traiettoria:

[math]1,640 \rightarrow 2,665 \rightarrow 4,048 \rightarrow 5,189 \rightarrow 5,711 \rightarrow 5,862[/math]

Dal punto di vista manageriale il messaggio è molto forte:

il rischio non sta semplicemente aumentando; sta attraversando una soglia decisionale.

Il primo trimestre è ancora gestibile

Nel Q1:

[math]EML = 1,640M€[/math]

contro una soglia di:

[math]2M€[/math]

Il rischio è significativo ma non ancora materialmente critico secondo il criterio scelto.

È il momento migliore per intervenire?

Non necessariamente.

Ma è sicuramente il momento migliore per valutare le alternative.

Questa distinzione è importante.

Il Risk Intelligence System non deve ordinare automaticamente di spendere.

Deve anticipare il momento nel quale la decisione diventerà urgente.

Nel Q2 cambia la natura del problema

Nel Q2:

[math]EML = 2,665M€[/math]

La soglia è superata del:

[math]\displaystyle \frac{2,665 – 2}{2} \times 100 \approx 33,2\%[/math]

Quindi l’esposizione attesa è circa il 33% superiore alla soglia decisionale.

Il problema non è più soltanto tecnologico.

Diventa economico.

Questo è precisamente il valore del TTR:

[math]\boxed{TTR = Q2}[/math]

Il management ha identificato una deadline di rischio, non una semplice percentuale.

Il paradosso: aspettare aumenta il valore dell’intervento ma riduce il tempo per realizzarlo

A questo punto introduciamo il TOM, il Target Operating Model.

Supponiamo che il progetto:

• costi €500.000;
• richieda due trimestri;
• riduca l’EML del 70% una volta operativo.

L’errore sarebbe dire:

“Costa solo €500.000.”

Il costo vero dipende anche dal tempo necessario a produrre il beneficio.

Se il progetto viene approvato oggi e richiede due trimestri, il beneficio comincerà dal Q3.

Questa assunzione è fondamentale.

Come si calcola il beneficio del TOM?

Indichiamo con:

[math]\alpha = 70\%[/math]

l’efficacia del TOM.

Una volta operativo:

[math]EML^{TOM}_t = EML^{baseline}_t(1 – \alpha)[/math]

Il beneficio economico è quindi:

[math]\Delta EML_t = EML^{baseline}_t – EML^{TOM}_t[/math]

e dunque:

[math]\displaystyle \boxed{ \Delta EML_t = EML^{baseline}_t \alpha }[/math]

Nel Q3:

[math]\Delta EML_{Q3} = 4,048 \times 0,70[/math]

[math]\boxed{ \Delta EML_{Q3} = 2,834M€ }[/math]

Nel Q4:

[math]\Delta EML_{Q4} = 5,189 \times 0,70[/math]

[math]\boxed{ \Delta EML_{Q4} = 3,633M€ }[/math]

e così via.

I cash flow del progetto

Il progetto richiede due trimestri.

Pertanto:

Questa è la struttura corretta dei flussi.

Non attribuiamo benefici durante la fase di implementazione.

Calcolo dell’NPV

Utilizziamo un tasso di sconto annuale dell’8%.

Il tasso trimestrale equivalente è:

[math]r_q = (1 + 0,08)^{1/4} – 1[/math]

[math]r_q \approx 1,943\%[/math]

L’NPV è:

[math]\displaystyle NPV = \sum_{t=0}^{T} \frac{CF_t}{(1 + r_q)^t}[/math]

Il codice è:

def calcola_npv_tom(
    df,
    costo_tom,
    trimestri_implementazione,
    abbattimento_rischio,
    tasso_annuo=0.08
):
    """
    Calcola il NPV del TOM.

    L'EML è interpretata come perdita
    attesa riferita al singolo periodo.

    Il beneficio inizia dal trimestre
    successivo al completamento
    dell'implementazione.
    """

    if costo_tom < 0: raise ValueError( "Il costo del TOM deve essere >= 0"
        )

    if not 0 <= abbattimento_rischio <= 1:
        raise ValueError(
            "L'abbattimento deve essere "
            "compreso tra 0 e 1"
        )

    if trimestri_implementazione < 0: raise ValueError( "I trimestri di implementazione " "devono essere >= 0"
        )

    tasso_trimestrale = (
        (1 + tasso_annuo) ** (1 / 4)
    ) - 1

    cash_flows = [-costo_tom]

    for trimestre, eml in enumerate(
        df["EML (€M)"],
        start=1
    ):

        if trimestre > trimestri_implementazione:

            beneficio = (
                eml * abbattimento_rischio
            )

        else:

            beneficio = 0.0

        cash_flows.append(beneficio)

    npv = npf.npv(
        tasso_trimestrale,
        cash_flows
    )

    return npv, cash_flows

Eseguiamo:

npv, cash_flows = calcola_npv_tom(
    df=df_risultati,
    costo_tom=0.5,
    trimestri_implementazione=2,
    abbattimento_rischio=0.70,
    tasso_annuo=0.08
)

print("Cash flow:")
print(cash_flows)

print(
    f"NPV TOM: €{npv:.3f}M"
)

 Output  dell’NPV

Il risultato è:

Cash flow:
[-0.5,
  0.0,
  0.0,
  2.8337618866,
  3.6325633156,
  3.9977689394,
  4.1032263279]

NPV TOM: €12.825M

Ma €12,825 milioni non deve diventare un numero “magico”

Qui dobbiamo fare un passo ulteriore.

Il risultato di €12,825 M è estremamente positivo.

Ma non significa che l’azienda incasserà €12,825 milioni.

Il valore rappresenta il NPV dei benefici attesi derivanti dalla riduzione dell’EML, sotto le ipotesi adottate.

Dipende quindi da:

[math]NPV = f( MME, P(D|E), \alpha, T_{implementazione}, r, C_{TOM} )[/math]

Se cambiamo una sola di queste variabili, il risultato cambia.

Per questo una Risk Intelligence seria non dovrebbe mai presentare un singolo NPV senza sensitivity analysis.

Sensitivity analysis: cosa succede se il TOM è meno efficace?

Supponiamo che il TOM non riesca a ridurre l’EML del 70%.

Potrebbe ridurlo del:

• 20%;
• 40%;
• 50%;
• 60%;
• 70%;
• 80%.

Possiamo verificare:

def sensitivity_abbattimento(
    df,
    costo_tom=0.5,
    trimestri_implementazione=2,
    tasso_annuo=0.08
):

    risultati = []

    livelli = [
        0.20,
        0.40,
        0.50,
        0.60,
        0.70,
        0.80
    ]

    for abbattimento in livelli:

        npv, _ = calcola_npv_tom(
            df=df,
            costo_tom=costo_tom,
            trimestri_implementazione=(
                trimestri_implementazione
            ),
            abbattimento_rischio=abbattimento,
            tasso_annuo=tasso_annuo
        )

        risultati.append({
            "Abbattimento EML":
                abbattimento,
            "NPV (€M)": round(npv, 3)
        })

    return pd.DataFrame(
        risultati
    )


df_sensitivity = sensitivity_abbattimento(
    df_risultati
)

print(df_sensitivity)

Il risultato è:

   Abbattimento EML  NPV (€M)
0              0.20      3.293
1              0.40      6.586
2              0.50      8.231
3              0.60      9.877
4              0.70     12.825
5              0.80     13.172

Un’osservazione importante

Questi valori evidenziano una caratteristica del modello.

L’NPV cresce al crescere dell’efficacia del TOM.

Tuttavia, prima di utilizzare questa tabella in un business case reale, è necessario verificare anche l’orizzonte temporale e la capacità del modello di rappresentare correttamente l’EML futuro.

Il messaggio manageriale corretto non è:

“Il TOM vale sempre €12,8 milioni.”

È:

“Il business case rimane positivo anche con un’efficacia sensibilmente inferiore all’ipotesi centrale.”

Una sensitivity ancora più importante: il timing

L’efficacia non è l’unica variabile.

C’è una domanda ancora più importante:

Cosa succede se ritardiamo la decisione?

Possiamo simulare un ritardo di:

• 0 trimestri;
• 1 trimestre;
• 2 trimestri;
• 3 trimestri.

def sensitivity_timing(
    df,
    costo_tom=0.5,
    abbattimento_rischio=0.70,
    tasso_annuo=0.08
):

    risultati = []

    for ritardo in range(4):

        trimestri_implementazione = (
            2 + ritardo
        )

        npv, _ = calcola_npv_tom(
            df=df,
            costo_tom=costo_tom,
            trimestri_implementazione=(
                trimestri_implementazione
            ),
            abbattimento_rischio=(
                abbattimento_rischio
            ),
            tasso_annuo=tasso_annuo
        )

        risultati.append({
            "Ritardo (trimestri)":
                ritardo,
            "Implementazione totale":
                trimestri_implementazione,
            "NPV (€M)": round(npv, 3)
        })

    return pd.DataFrame(
        risultati
    )


df_timing = sensitivity_timing(
    df_risultati
)

print(df_timing)

   Ritardo (trimestri)  Implementazione totale  NPV (€M)
0                    0                       2    12.825
1                    1                       3    10.150
2                    2                       4     6.787
3                    3                       5     3.156

Con l’orizzonte di sei trimestri utilizzato nel caso studio, il risultato mostra una conseguenza intuitiva:

• più tardi arriva la protezione;
• meno trimestri producono benefici;
• più rapidamente si riduce il valore dell’intervento.

Questa è la vera natura del costo dell’attesa.

Il break-even: quanta efficacia serve per giustificare l’investimento?

Possiamo fare ancora meglio.

Cerchiamo il valore di [math]\alpha[/math] per cui:

[math]NPV = 0[/math]

La formula è:

[math]NPV = -C_0 + \alpha PV(EML)[/math]

Perciò:

[math]\displaystyle \alpha^* = \frac{C_0}{PV(EML)}[/math]

Questo valore rappresenta la riduzione minima dell’EML necessaria affinché il progetto sia economicamente neutrale.

È una metrica molto utile in una riunione del board.

Invece di chiedere:

“Siamo sicuri che il progetto ridurrà il rischio del 70%?”

possiamo chiedere:

“Qual è la riduzione minima del rischio necessaria per recuperare l’investimento?”

È una domanda molto più concreta.

Il vero costo dell’attesa

Possiamo ora formalizzare il concetto centrale dell’articolo.

Supponiamo di avere:

[math]NPV_0[/math]

per una decisione presa oggi e:

[math]NPV_k[/math]

per la stessa decisione rinviata di [math]k[/math] trimestri.

Definiamo:

[math]Cost_{attesa} = NPV_0 – NPV_k[/math]

Se:

[math]NPV_0 > NPV_k[/math]

il ritardo distrugge valore.

Non necessariamente perché il progetto sia diventato più costoso.

Ma perché ha perso alcuni periodi nei quali avrebbe potuto produrre benefici.

Questa è una distinzione manageriale fondamentale.

Perché il rischio non è una fotografia

Possiamo ora tornare alla domanda iniziale.

Nel Q1 abbiamo:

[math]EML = 1,640M€[/math]

Nel Q2:

[math]EML = 2,665M€[/math]

Nel Q3:

[math]EML = 4,048M€[/math]

Se il management osservasse soltanto il Q1, potrebbe concludere:

“Il rischio è gestibile.”

Il Risk Intelligence System aggiunge però una seconda informazione:

“Il rischio è gestibile oggi, ma la traiettoria indica che la soglia sarà superata nel prossimo trimestre.”

Questa informazione cambia completamente la decisione.

Il ruolo del CFO

Un CFO non ha bisogno di sapere che:

[math]P(D) = 68,8\%[/math]

perché il numero, da solo, non determina una decisione.

Ha bisogno di sapere:

[math]EML = 4,048M€[/math]

e:

[math]TTR = Q2[/math]

e soprattutto:

[math]NPV_{TOM} > 0[/math]

a determinate condizioni.

La sequenza decisionale diventa:

1. Quanto siamo esposti?

[math]EML[/math]

2. Quanto rapidamente peggiora?

[math]\Delta EML_t[/math]

3. Quando superiamo la soglia?

[math]TTR[/math]

4. Quanto costa intervenire?

[math]C_{TOM}[/math]

5. Quanto rischio possiamo eliminare?

[math]\alpha[/math]

6. Conviene economicamente?

[math]NPV[/math]

Questo è il passaggio dalla risk measurement alla risk economics.

Cosa succede se il management aspetta la certezza?

La tentazione più comune è aspettare che la disruption sia evidente.

Nel nostro scenario:

[math]P(D|E) = 27,9\%[/math]

nel Q1.

Nel Q2:

[math]45,3\%[/math]

Nel Q3:

[math]68,8\%[/math]

Nel Q4:

[math]88,3\%[/math]

Nel Q5:

[math]97,1\%[/math]

Aspettare il 97,1% potrebbe sembrare prudente.

Ma dal punto di vista decisionale potrebbe essere l’opposto.

A quel punto l’azienda non sta più cercando di prevenire la disruption.

Sta cercando di recuperare il terreno perduto.

Il valore della Risk Intelligence consiste proprio nel fornire un segnale quando esiste ancora tempo per agire.

Un sistema di early warning, non una sfera di cristallo

È importante non attribuire al modello capacità che non possiede.

Il sistema non può prevedere con certezza:

• il comportamento dei consumatori;
• la velocità di adozione dell’AI;
• le mosse dei concorrenti;
• i cambiamenti degli algoritmi;
• la severità futura della disruption.

Può però fare qualcosa di molto utile.

Può aggiornare continuamente la valutazione del rischio.

In questo senso è più corretto parlare di:

early-warning system

che di sistema predittivo.

La differenza è sostanziale.

Un modello predittivo cerca di dire:

“Questo accadrà.”

Un sistema di Risk Intelligence cerca di dire:

“Alla luce delle nuove evidenze, la nostra posizione è cambiata. Dobbiamo aggiornare la decisione.”

Come trasformare il prototipo in un sistema aziendale

Il modello Python rappresenta soltanto il motore concettuale.

In produzione potrebbe essere alimentato da dati provenienti da:

Marketing

• traffico organico;
• branded search;
• conversion rate;
• CAC;
• retention;
• customer acquisition.

Customer journey

• touchpoint;
• canali;
• tempo di conversione;
• interazioni con assistenti AI;
• percentuale di traffico diretto.

Competitive intelligence

• nuovi prodotti;
• nuovi canali;
• agenti AI;
• modifiche al pricing;
• partnership tecnologiche.

Finance

• margine;
• volumi;
• esposizione per canale;
• EBITDA;
• cash flow;
• costi di trasformazione.

Il risultato potrebbe essere una dashboard aggiornata automaticamente:

┌─────────────────────────────────────┐
│       RISK INTELLIGENCE DASHBOARD   │
├─────────────────────────────────────┤
│ JFI                  0.320           │
│ P(Disruption)        68.8%           │
│ EML                  €4.048 M        │
│ TTR                  Q2              │
│ TOM Cost             €0.500 M        │
│ Risk Reduction       70%             │
│ NPV                  €12.825 M       │
└─────────────────────────────────────┘

Il CFO non deve leggere il codice.

Deve leggere la decisione che il codice supporta.

I cinque indicatori che contano

Possiamo riassumere il framework in cinque metriche.

Nessuno dei cinque è sufficiente da solo.

La loro forza deriva dalla combinazione.

30. Le limitazioni del framework

Un modello credibile deve dichiarare i propri limiti.

JFI

È un indice euristico.

I pesi devono essere calibrati.

Bayes

Le likelihood sono ipotesi o stime.

Le evidenze correlate possono generare double counting.

EML

L’interpretazione utilizzata è quella di perdita attesa per periodo.

Non deve essere automaticamente sommata come perdita realizzata.

NPV

Il risultato dipende dalle ipotesi su:

• efficacia;
• timing;
• costo;
• durata;
• tasso di sconto.

Orizzonte temporale

Se il TOM produce benefici oltre Q6, il modello dovrebbe estendere l’orizzonte.

Questo è particolarmente importante perché un orizzonte troppo breve può sottostimare il valore di un investimento con benefici di lungo periodo.

La vera domanda non è “quanto rischio abbiamo?”

Il passaggio concettuale più importante è questo.

La domanda tradizionale è:

“Quanto rischio abbiamo?”

Il framework propone una sequenza diversa:

“Come sta cambiando?”

Poi:

“Quando supera la soglia?”

Poi:

“Quanto costa aspettare?”

E infine:

“Quanto vale intervenire adesso?”

È un cambiamento radicale.

Il rischio diventa una variabile dinamica.

Il tempo diventa una variabile economica.

La decisione diventa misurabile.

Il valore del rischio sta anche nel tempo

La tecnologia non cambia soltanto i prodotti.

Può cambiare il modo in cui il cliente cerca, confronta e acquista.

Per questo una misura statica dell’esposizione può essere insufficiente.

Nel nostro caso studio partiamo da:

[math]MME = 5,88M€[/math]

e:

[math]P(D) = 18,1\%[/math]

che producono:

[math]EML = 1,064M€[/math]

La situazione iniziale sembra gestibile.

Ma l’aggiornamento progressivo delle evidenze porta l’EML a:

[math]1,640 \rightarrow 2,665 \rightarrow 4,048 \rightarrow 5,189 \rightarrow 5,711 \rightarrow 5,862[/math]

milioni di euro.

La soglia di €2 milioni viene superata nel:

[math]\boxed{Q2}[/math]

Il Time-to-Risk è quindi Q2.

A quel punto entra in gioco il TOM.

Un investimento di:

[math]€0,5M[/math]

con due trimestri di implementazione e un’ipotesi di riduzione dell’EML del 70% genera, nello scenario simulato:

[math]\boxed{NPV = €12,825M}[/math]

Ma il numero più importante non è €12,825 milioni.

È il principio che il modello rende visibile:

[math]\displaystyle \boxed{ Il\ valore\ di\ una\ decisione\ dipende\ anche\ da\ quando\ viene\ presa. }[/math]

Aspettare non è una posizione neutrale.

Quando il rischio cresce, il rinvio può significare perdere trimestri nei quali l’intervento avrebbe già prodotto benefici.

La Risk Intelligence serve proprio a rendere visibile questo fenomeno.

Non promette certezza.

Non elimina l’incertezza.

Non sostituisce il giudizio del management.

Fa qualcosa di più utile:

trasforma segnali deboli, probabilità, esposizione economica e tempi di reazione in una struttura quantitativa per decidere.

La sequenza finale può essere sintetizzata così:

[math]\displaystyle \boxed{ Segnali \rightarrow Fragilità \rightarrow Probabilità \rightarrow Perdita\ attesa \rightarrow Scadenza \rightarrow Intervento \rightarrow Valore }[/math]

La domanda strategica non è quindi soltanto:

“Quanto ci costerà la disruption?”

La domanda più importante è:

“Quanto ci costa aspettare di essere sicuri che stia arrivando?”

Ed è proprio in questo spazio tra incertezza e decisione che nasce il valore della Risk Intelligence.