C'è una frase che mi capita di sentire sempre più spesso, detta quasi di passaggio mentre si chiude una call e si torna alle cose “vere”: a noi interessa il go-live. La compliance è roba vostra.
Non sempre è arroganza. Anzi, di solito è l'opposto. È una frase detta con la naturalezza di chi pensa che la compliance sia un dettaglio tecnico, come scegliere un framework o decidere se mettere il bottone a destra o a sinistra.
Solo che quel “dettaglio” sta cambiando forma. E sta diventando, molto più velocemente di quanto il mercato sembri pronto ad ammettere, una questione di responsabilità.
Quello che il cliente compra e quello che il fornitore vende #
Per anni, nel software su commessa, ci siamo capiti con un patto implicito abbastanza semplice. Il cliente descrive cosa vuole, il fornitore lo costruisce, si concordano tempi e costi, e alla consegna si fa collaudo, si va in produzione, si chiude.
In questo modello la responsabilità “pesante” finiva quasi sempre dentro il perimetro del progetto. Se qualcosa andava storto, si parlava di bug, di disservizi, magari di una penale. Fastidioso, certo, ma gestibile.
Il punto è che in europa, tra il 2025 e il 2027, sta arrivando un cambio di prospettiva che rende quel patto meno stabile. Non è un singolo regolamento che puoi ignorare finché non arriva la mail del legale. È un insieme di regole che, viste nel loro complesso, spingono in una direzione precisa: il software viene trattato sempre più come un prodotto.
E quando qualcosa è un prodotto, chi lo “produce” non risponde più solo in termini contrattuali. Risponde anche per i difetti, un po' come succede con un elettrodomestico che fa danni perché è stato progettato o assemblato male.
Il disallineamento commerciale che crea attrito #
Qui nasce la frizione vera, quella che poi esplode nelle trattative e nei preventivi.
Il committente ragiona in modo lineare e, dal suo punto di vista, anche corretto. Vuole una piattaforma funzionante, un portale, un'app. La vuole entro una data, con un certo budget, con le feature che servono al business.
Il fornitore, però, si trova addosso un carico crescente di requisiti che non compaiono quasi mai nel brief. Non li trovi nelle user story, non li vedi nei mockup, non te li chiede il product owner. Eppure sono cose che, se mancano, trasformano un progetto “consegnato” in un progetto “rischioso”.
Parlo di documentazione tecnica fatta in un certo modo, tracciabilità delle componenti, gestione delle vulnerabilità, trasparenza su certe scelte algoritmiche, accessibilità. Tutte attività che hanno una caratteristica comune: costano tempo, competenze, processo.
E qui arriva il dilemma che, secondo me, sta diventando sempre più tossico.
Se le metti nel preventivo, rischi di essere più caro del concorrente che non le mette.
Se non le metti, le assorbi nel margine, lavori in perdita e, in più, ti prendi un rischio che non hai esplicitato.
Nessuna delle due strade è sostenibile a lungo.
Perché “è sempre stato così” non regge più #
Nel b2b italiano abbiamo vissuto per anni dentro una cultura del “facciamo, poi vediamo”. Contratti leggeri, specifiche vaghe, molta fiducia personale. A volte ha funzionato anche bene, non lo nego. Forse perché il contesto lo permetteva.
Ora però stanno cambiando tre cose insieme, e la combinazione è quella che fa paura.
La prima è la responsabilità più “oggettiva”. In alcuni scenari non basta più dire “non siamo stati negligenti”. Conta il difetto e conta il danno. E in certi casi il peso di dimostrare che non c'era difetto si sposta su chi ha prodotto o immesso sul mercato.
La seconda è l'allargamento del perimetro. Il software non è solo quello che scrivi tu. È anche ciò che integri: librerie open source, servizi cloud, api di terze parti, modelli ai. E quando queste cose entrano nel prodotto finale, qualcuno deve rispondere di come sono state scelte, integrate, monitorate.
La terza è il tempo. Non parliamo di un futuro lontano. Parliamo di scadenze tra il 2026 e il 2027. Il codice che stai scrivendo adesso, con buona probabilità, sarà ancora lì quando queste regole saranno pienamente operative.
E allora mi chiedo se non sia ingenuo continuare a trattare la compliance come una postilla.
La conversazione che nessuno vuole avere #
La parte più difficile non è capire la norma. È parlarne senza far saltare il tavolo commerciale.
Prova a dire a un cliente che il preventivo aumenta del 20% perché devi produrre documentazione tecnica conforme, implementare un processo di gestione delle vulnerabilità e mantenere un inventario aggiornato delle componenti.
Nel migliore dei casi ti risponde con un silenzio lungo.
Nel peggiore ti dice che qualcun altro glielo fa senza.
Ed è qui che il mercato si spacca. Perché quel “senza” raramente significa “più efficiente”. Spesso significa “debito di compliance”, cioè lavoro e rischio spostati nel futuro. Un futuro in cui, con le nuove regole, il conto potrebbe arrivare al fornitore, al committente, o a entrambi.
Eppure questa conversazione non la sta facendo quasi nessuno, almeno non in modo esplicito. È scomoda. Costringe il cliente ad accettare che la compliance ha un costo reale. E costringe il fornitore a spiegare quel costo senza nascondersi dietro parole che sembrano burocrazia.
Il costo dell'invisibilità #
C'è un paradosso che rende tutto più complicato. Le attività di compliance, quando sono fatte bene, sono invisibili.
Un sistema serio di gestione vulnerabilità si nota quando non succede niente.
La documentazione tecnica diventa preziosa quando qualcosa va storto.
Un inventario delle componenti (tipo un elenco aggiornato delle dipendenze) vale davvero il giorno in cui esce una vulnerabilità critica e tu devi capire subito se sei esposto.
Il cliente vede la feature, vede il go-live, vede l'interfaccia. Tutto quello che tiene in piedi quel risultato nel tempo resta sotto il pavimento.
E allora forse il problema non è che il cliente “non vuole pagare”. È che non percepisce cosa sta comprando.
Se vai da un imprenditore e gli dici “dobbiamo implementare un software bill of materials conforme”, probabilmente perdi attenzione dopo poche parole.
Se invece gli dici “dobbiamo essere in grado, entro 24 ore, di sapere se una vulnerabilità appena uscita mette a rischio il tuo prodotto e quindi la tua responsabilità”, stai parlando la lingua del rischio. Che è una lingua molto più universale.
Cosa cambia, in pratica, senza trasformare tutto in un incubo #
Per i fornitori, la strada è stretta ma abbastanza chiara. Bisogna smettere di trattare la compliance come un costo nascosto e iniziare a trattarla come un servizio esplicito, con un valore che si può raccontare.
Vuol dire, per esempio, separare lo sviluppo funzionale dalla manutenzione di sicurezza e conformità. Non dentro un “canone annuale” indistinto, ma con una voce che dica cosa copre davvero. Anche perché, se un domani qualcosa finisce in discussione, l'ambiguità non aiuta nessuno.
Vuol dire mettere nero su bianco, nei contratti, chi fa cosa. Chi aggiorna le dipendenze? Chi monitora le vulnerabilità? Chi produce e conserva la documentazione tecnica? Chi decide se una libreria si può usare o no? Chi risponde se un componente si rivela compromesso?
Oggi, in molti contratti italiani, queste domande semplicemente non esistono. E quando una domanda non esiste, la risposta arriva sempre nel momento peggiore.
Vuol dire anche imparare a vendere queste attività per quello che sono: riduzione del rischio. Perché il cliente non compra “compliance”. Compra la possibilità di non trovarsi con un prodotto fuorilegge, con un incidente di sicurezza gestito male, o con una contestazione in cui non ha prove e documenti per difendersi.
Per i committenti il cambio di mentalità è speculare. La compliance è roba vostra non è più una posizione comoda, e forse non è mai stata davvero una posizione sicura. Se immetti sul mercato un prodotto digitale, anche se lo hai fatto sviluppare da terzi, la responsabilità non evapora.
Al massimo puoi rivalerti contrattualmente sul fornitore. Ma nel frattempo il danno, la reputazione, la gestione dell'incidente e le conseguenze commerciali le affronti tu.
Una questione di maturità del mercato #
A pensarci bene, quello che sta succedendo assomiglia a una crescita forzata. Il mercato del software, soprattutto quello su commessa, sta passando da un modello artigianale, basato su fiducia e accordi impliciti, a un modello più industriale, dove le responsabilità sono definite, i processi sono documentati e la qualità non è solo “funziona sul mio telefono”.
Non è per forza una cattiva notizia.
Per i fornitori seri può diventare un modo per distinguersi da chi compete solo tagliando angoli.
Per i committenti più consapevoli può essere una garanzia: sapere che il software non è costruito solo per andare online, ma per restare in piedi, reggere gli incidenti, e non trasformarsi in un problema legale al primo scossone.
Forse la frase giusta, oggi, non è “la compliance è roba vostra”. È qualcosa di più onesto e più utile: la compliance è parte del prodotto.
E allora sì, è un costo strutturale del fare software. Prima lo riconosci, prima lo puoi gestire. E magari, con un po' di coraggio, trasformarlo anche in un vantaggio competitivo.