Capita più spesso di quanto si pensi: qualcuno in azienda, magari senza un background da sviluppatore, con l'aiuto di un assistente AI mette insieme un gestionale interno — anagrafiche, fatturazione, magazzino — che sembra funzionare bene e costa una frazione di una soluzione professionale. La domanda da farsi prima di affidargli dati aziendali reali non è "funziona?", ma "cosa non sto vedendo?".
Perché "sembra funzionare" non basta
Un software può apparire perfettamente funzionante nell'uso quotidiano e avere allo stesso tempo problemi gravi che restano invisibili finché non si manifestano — spesso nel momento peggiore possibile. Non è una questione di sfortuna: è la differenza tra codice che è stato testato per lo scenario "tutto va bene" e codice pensato fin dall'inizio anche per gli scenari in cui qualcosa va storto.
I rischi concreti più comuni
| Area | Cosa può andare storto | Conseguenza reale |
|---|---|---|
| Sicurezza | Password deboli o in chiaro, nessuna protezione contro attacchi comuni (SQL injection, XSS) | Violazione dati clienti, obblighi di notifica al Garante Privacy |
| Backup | Nessuna copia dei dati, o copie mai testate | Perdita totale e irreversibile dell'anagrafica clienti/fatture in caso di guasto |
| Continuità | Un solo referente che "sa come funziona" il sistema | Se quella persona lascia l'azienda o è irraggiungibile, nessuno sa risolvere un problema |
| Conformità | Nessuna attenzione a GDPR, tracciabilità fiscale, requisiti di settore | Sanzioni amministrative, problemi in caso di controllo |
| Scalabilità | Architettura che regge pochi utenti/record | Il sistema rallenta o si blocca proprio quando l'azienda cresce |
Le domande da fare prima di fidarsi
- Cosa succede se il computer o il server su cui gira si rompe oggi? C'è un backup verificato, non solo presente?
- Chi altro, oltre a chi lo ha costruito, è in grado di modificarlo o risolvere un problema?
- I dati personali dei clienti sono trattati in modo conforme al GDPR (accesso controllato, cifratura, base giuridica del trattamento)?
- Il sistema è mai stato messo alla prova con un volume di dati realistico, non solo con i pochi record usati durante lo sviluppo?
- Esiste una documentazione minima, o la conoscenza del sistema vive solo nella testa di una persona?
Se anche una sola di queste domande non ha una risposta chiara, il rischio non è teorico: è già presente, semplicemente non si è ancora manifestato.
Non è una questione di buona fede
Chi costruisce questi sistemi lo fa quasi sempre con le migliori intenzioni, spesso risolvendo un problema reale a costo quasi zero, ed è comprensibile la tentazione di continuare così. Il punto non è la competenza o l'impegno di chi lo ha realizzato: è che programmazione, sicurezza, backup e conformità normativa sono discipline distinte, ciascuna con anni di prassi consolidata alle spalle, e un assistente AI — per quanto capace — non le somma automaticamente in chi lo utilizza senza quel background.
Quando è il momento di professionalizzare
Un sistema "fatto in casa" può essere del tutto ragionevole per validare un'idea o gestire un processo marginale a basso rischio. Ma quando inizia a gestire dati reali di clienti, fatturazione, o un processo da cui dipende l'operatività quotidiana, il costo di una valutazione professionale — anche solo un audit di sicurezza e affidabilità, senza necessariamente riscrivere tutto da zero — è quasi sempre inferiore al costo potenziale di scoprire un problema critico nel momento peggiore, quando ormai il sistema è al centro dell'attività aziendale.