Il contesto storico: da terminali a PC e internet

Dai primi personal computer ai software “fai da te”, fino all’intelligenza artificiale, le mode tecnologiche hanno spesso spinto gli utenti a chiedere sempre di più ai sistemi informativi. All’inizio, i terminali erano semplici scatoloni con schermo nero e caratteri verdi: strumenti di lavoro limitati a poche postazioni, senza alcuna aspettativa di funzioni aggiuntive. Con l’avvento dei PC, delle interfacce grafiche e di Internet, le richieste crebbero in modo significativo, alimentando una cultura di sperimentazione spesso incontrollata.

Il “no” come principio pedagogico

Il concetto di dire “no” come strumento di crescita non è nuovo. “I no che aiutano a crescere” è un testo pedagogico di Asha Phillips, che spiega come, talvolta, rifiutare richieste ai figli favorisca lo sviluppo caratteriale, mentre concedere sempre tutto può avere ripercussioni a lungo termine. Qui trasponiamo lo stesso principio al mondo degli IT manager e dei loro colleghi, i quali devono spesso frenare ambizioni innovative per motivi di prudenza, sicurezza e responsabilità.

Il fenomeno “ubellino” e le sue declinazioni

Negli anni ’90 nacque il termine “ubellino”, l’esclamazione “Uh, bellino!” rivolta a software nuovi e colorati, anche se inutili. Alcuni li chiamavano “gorgonzolaware” o “incatzware”, evidenziando la loro bellezza estetica priva di reale valore. In quel periodo, le riviste mensili allegavano CD o DVD con decine di programmi, molti in versione demo. Un collega, ad esempio, doveva reinstallare il computer ogni due mesi a causa dell’accumulo di “ubellini” che “incriccavano” il sistema, anche se con Windows 95 non era difficile bloccare il sistema.

Le prime politiche di sicurezza e l’avvento dei “utonti”

Con l’arrivo di Windows 2000 e l’introduzione di politiche di sicurezza più stringenti, l’installazione compulsiva fu arginata, ma non la creatività informatica degli utenti. Da qui nasce il termine non propriamente garbato “utonti”, ampiamente diffuso in campo IT per indicare utenti che, pur senza competenze, installano e modificano software a loro piacimento.

Software “fai da te” e le loro implicazioni

L’evoluzione delle suite di ufficio, in particolare Microsoft Office, introdusse ambienti di sviluppo visuale con database relazionale (MS Access). Nacquero applicativi “fai da te”, spesso partiti da una semplice tabella Excel trasformata in un file Access con form aggiuntivi. Molti di questi programmi, realizzati con estro, divennero applicativi di settore, ma presentavano problemi critici al pensionamento o al trasferimento del creatore, costringendo i responsabili a dire “no” e a cercare soluzioni più robuste.

L’intelligenza artificiale: opportunità e avvertimenti

L’AI presenta enormi potenzialità ma anche problemi di fondo. È attraente, semplifica processi complessi e offre soluzioni rapide, tanto che frasi come “L’ho fatto con Claude! Lo chiedo a ChatGPT!” stanno diventando il nuovo “Lo dice Google”. Tuttavia, il lavoro di generazioni di programmatori, dagli anni ’60 ad oggi, non può essere appreso in pochi giorni né sostituito completamente da un Large Language Model (LLM).

Caveat dell’AI

    • Complessità nascosta: L’AI maschera la complessità reale dei processi.
    • Riduzione della qualità del software: L’affidabilità, soprattutto in ambito sanitario, sta degradando anno dopo anno.
    • Difficoltà di manutenzione: Bug, versioning e sicurezza diventano più difficili da gestire.

Esempi concreti di rischi

Un caso emblematico è quello di un software sanitario che, a causa di bug non rilevati, costò decine di milioni di dollari. L’articolo originale è disponibile su HealthTech360. Inoltre, la comparazione con la formazione di un cardiochirurgo – laurea, specializzazione e anni di gavetta – sottolinea come la scrittura di codice non possa essere ridotta a un’attività di “click‑and‑go”.

Il valore della competenza tecnica

Nonostante esistano programmatori brillanti senza lauree o certificazioni, la qualità del software, soprattutto in settori critici, sta peggiorando. La dipendenza dall’AI rischia di accentuare questo trend, rendendo più arduo l’eliminazione dei bug e la messa in sicurezza dei sistemi. Come una volta era necessario conoscere il funzionamento del “spinterogeno” per ottenere la patente di guida, oggi basta sapere dove mettere la benzina, ma il rischio è che la conoscenza profonda del “cosa c’è dentro” venga persa.

Le raccomandazioni per gli RTD

L’invito per i Responsabili per la Transizione Digitale è chiaro: essere prudenti nella diffusione di strumenti basati su AI, anche a costo di risultare impopolari. L’AI può creare dipendenza e, in un’Europa che parla finalmente di sovranità digitale, è fondamentale esercitare un controllo critico.

Pratiche consigliate

    • Valutare l’impatto di ogni nuova applicazione prima dell’adozione.
    • Implementare policy di sicurezza che richiedano autorizzazioni formali per installazioni e aggiornamenti.
    • Promuovere la formazione continua del personale IT su architetture, bug‑fixing e best practice.
    • Stabilire procedure di audit periodico per verificare la conformità e la qualità del codice.

Conclusioni: il “no” come strumento di innovazione responsabile

Dire “no” non è un gesto di chiusura, ma un atto di responsabilità. Gli IT manager, soprattutto in ambiti sensibili come quello sanitario (es. Azienda Ospedaliero‑Universitaria Careggi – UOC Sviluppo e Gestione Tecnologie Innovative), devono bilanciare l’entusiasmo per le novità con la necessità di garantire sicurezza, affidabilità e sostenibilità. Solo così l’innovazione potrà progredire senza compromettere la qualità dei servizi.

Iscriviti alla newsletter per ricevere articoli di tuo interesse e prendi visione dell’Informativa Privacy, selezionando la casella di consenso. Sono un ingegnere boomer che non ha perso la voglia di