Cos'è la dipendenza da un fornitore IT unico?

La dipendenza da fornitore unico è il rischio organizzativo di affidare un sistema critico, un'intera area tecnologica o il rapporto con l'AI a un solo fornitore IT, al punto che l'azienda non ha più visibilità né alternativa se quel fornitore sparisce, cambia condizioni o perde le persone chiave che conoscevano il progetto. Non va confusa con il vendor lock-in, che è il costo tecnico di uscire da una tecnologia: qui il problema non è la tecnologia, è avere un solo referente umano e commerciale per un pezzo essenziale del business. Il rischio ha tre facce concrete: continuità (il fornitore chiude, viene acquisito o cambia priorità e smette di seguirti), leva contrattuale (sa di essere insostituibile e alza prezzi o condizioni a rinnovo), e conoscenza (le competenze sul sistema vivono in due o tre persone di un'altra azienda, non nella tua). È un rischio da gestire, non da eliminare: un fornitore unico spesso è anche la scelta più efficiente.

Il referente unico non è il problema, è il rischio non gestito

Le aziende hanno una ragione legittima per cercare un fornitore unico: coordinare cinque fornitori diversi su uno stesso sistema, ognuno che rimanda la colpa all'altro quando qualcosa si rompe, è ingestibile in pratica, non solo in teoria. Il referente tecnico unico riduce l'attrito, velocizza le decisioni e rende chiaro chi risponde di cosa. Il punto non è quindi evitare la concentrazione su un fornitore, ma evitare che diventi una condizione di ostaggio: un'azienda può avere un solo referente operativo e restare comunque libera di cambiarlo, se possiede il codice e i dati che quel fornitore ha prodotto, se la documentazione tecnica resta in azienda e non nella testa di due consulenti, se l'architettura usa standard aperti invece di formati proprietari, e se le competenze vengono trasferite al team interno durante il progetto invece di restare trattenute come garanzia di rinnovo. Un fornitore che rifiuta sistematicamente questi quattro punti sta vendendo dipendenza, non un rapporto di fiducia, e va trattato come tale già in fase di trattativa, non quando il contratto scade.

Esempio enterprise e come si progetta l'uscita fin dall'inizio

Un caso ricorrente: un'azienda media affida a un unico system integrator la piattaforma dati e l'intero layer AI costruito sopra. Funziona bene per due anni, poi l'integratore viene acquisito da un competitor del cliente, e il rapporto si interrompe da un giorno all'altro. Chi resta in azienda ha accesso al codice, ma non alla documentazione delle scelte architetturali, mai scritta perché "tanto la sapevano loro". La ricostruzione costa più della piattaforma originale. Si evita progettando l'uscita all'inizio del rapporto, non alla fine: clausole contrattuali di trasferimento del codice e della proprietà intellettuale, un secondo fornitore o un CTO frazionale che mantenga visione tecnica indipendente anche quando l'esecuzione è delegata, verifica periodica della portabilità dei dati con un'estrazione reale, e un piano di trasferimento di competenze scritto nel contratto fin dal primo giorno, non negoziato in emergenza. La concentrazione su un solo fornitore diventa un rischio accettabile quando l'azienda resta, in ogni momento, in grado di cambiarlo senza che quel fornitore se ne accorga per primo.