Questa è una riflessione personale.
Lavoro nella tecnologia da molti anni e oggi dedico all’Intelligenza Artificiale moltissimo tempo, per lavoro ma anche per passione. In Atik la utilizziamo sempre di più nei nostri processi e nello sviluppo software.

Più la utilizzo, più sono convinto che sia una tecnologia straordinaria.

Ma più la utilizzo, più mi pongo anche una domanda:

l’AI sta realmente aumentando le nostre competenze o, qualche volta, ci sta semplicemente facendo credere di possedere competenze che non abbiamo?

Il rischio che vedo non è quello di ottenere un risultato mediocre.

È quasi il contrario.

Il rischio è ottenere qualcosa che ci sembra estremamente valido, senza possedere le competenze necessarie per capire quanto siano solide le fondamenta sulle quali è costruito.

E proprio perché funziona, iniziare a fidarci.

Fino magari ad affidargli processi importanti, dati critici o addirittura una parte del nostro business.

Prima almeno sapevamo di non sapere

Prima dell’AI esisteva un limite molto semplice.

Non sapevo programmare: difficilmente riuscivo a produrre un’applicazione.

Non conoscevo la finanza: difficilmente riuscivo a produrre autonomamente un’analisi finanziaria sofisticata.

Non conoscevo sufficientemente una materia legale: davanti a un contratto complesso sapevo di aver bisogno di qualcuno più competente di me.

Era un limite.

Ma era anche un sistema di allarme.

Oggi posso non conoscere una materia e ottenere qualcosa che ha perfettamente l’aspetto del lavoro di chi quella materia la conosce.

Ed è qui che nasce il dubbio: sono diventato competente o sono semplicemente diventato capace di produrre qualcosa che ha l’aspetto della competenza?


Nello sviluppo software la differenza si vede bene

In Atik abbiamo un team di sviluppo che utilizza quotidianamente l’AI.

La usiamo per analizzare codice, trovare errori, creare procedure, produrre test, confrontare alternative, ottimizzare parti di sviluppo.

La differenza di produttività è reale.

Ma il presupposto è completamente diverso da:

“Non conosco lo sviluppo, quindi faccio sviluppare il software all’AI.”

Lo sviluppatore sa dove vuole andare.

Conosce l’architettura.

Conosce il database.

Conosce le integrazioni.

Conosce le ragioni per cui determinate scelte sono state fatte.

E soprattutto possiede abbastanza competenza da guardare una proposta dell’AI e dire:

“No. Funziona, ma non voglio prendere questa strada.”

Questo succede.

L’AI può suggerire una soluzione tecnicamente corretta ma sbagliata per quel progetto.

Può essere superficiale.

Può non conoscere un vincolo.

Può ignorare un’integrazione.

Può modificare qualcosa che localmente sembra irrilevante ma che altrove è critico.

In questi casi la competenza non serve a scrivere più velocemente.

Serve a capire quando non seguire l’AI.


E se quella competenza non c’è?

È qui che il problema diventa serio.

Possiamo ottenere un’applicazione che:

  • funziona;
  • è veloce;
  • è bella;
  • soddisfa gli utenti;
  • non mostra bug evidenti.

E quindi convincerci di avere costruito un ottimo prodotto.

Ma cosa sappiamo realmente?

Il database è progettato bene?

Esistono ridondanze?

L’architettura reggerà la crescita?

È manutenibile?

È sicuro?

I dati sono protetti?

Esistono backup e procedure di recovery?

Come si integrerà con ERP, CRM, e-commerce, sistemi documentali, database o applicazioni esistenti?

Abbiamo progettato oggi pensando a ciò che dovrà fare tra tre anni?

Oppure abbiamo costruito un castello di carta che dall’esterno sembra un grattacielo?

Il punto è che un software può funzionare magnificamente oggi ed essere costruito su fondamenta fragili.

E domani chi ricorderà tutto?

C’è poi un’altra domanda che considero molto importante.

Supponiamo che buona parte del software sia stata costruita con l’AI.

Tra due anni dobbiamo modificarlo.

L’AI avrà realmente chiara tutta l’impostazione originale?

Ricorderà perché determinate decisioni erano state prese?

Saprà che una tabella viene utilizzata anche da un altro processo?

Conoscerà le dipendenze?

Saprà distinguere ciò che può modificare da ciò che non deve modificare?

Oppure rischierà di risolvere perfettamente un problema locale compromettendo una procedura o, peggio, dei dati?

A quel punto il tema non è più soltanto il codice.

È la memoria del progetto.

Architettura, documentazione, test, versionamento, dipendenze, procedure di rilascio e rollback diventano ancora più importanti quando l’AI entra profondamente nello sviluppo.

La sicurezza è il punto dove l’illusione può costare di più

Un software insicuro non necessariamente funziona male.

Può funzionare perfettamente.

Login corretto.

Documenti disponibili.

Dati salvati.

Processi operativi.

Tutto apparentemente in ordine.

Ma chi ha verificato autorizzazioni, esposizione delle API, gestione delle sessioni, credenziali, dipendenze, logging, cifratura, accessi ai dati?

L’AI conosce questi problemi e può aiutarci a verificarli.

Ma c’è sempre lo stesso paradosso:

per chiedere una verifica dobbiamo sapere che quella verifica serve.

Chi non ha competenze di sicurezza può vedere semplicemente un’applicazione che funziona.

Chi le ha può vedere una superficie di attacco.

E poi c’è la domanda più importante: chi ne risponde?

Questo secondo me è il punto che spesso viene completamente dimenticato.

Se un software sviluppato o modificato con l’AI perde dati, espone informazioni riservate, blocca un processo aziendale o produce un danno economico, chi se ne assume la responsabilità?

L’AI?

No.

In azienda la responsabilità rimane comunque in capo a qualcuno.

A chi ha deciso di utilizzare quella soluzione.

A chi l’ha approvata.

A chi l’ha messa in produzione.

A chi ne gestisce sicurezza, dati e continuità operativa.

E più il processo è critico, più questa domanda dovrebbe arrivare prima dello sviluppo, non dopo il problema.

Perché una cosa è sperimentare un automatismo interno.

Un’altra è costruire su quella soluzione un processo dal quale dipendono clienti, fatturazione, dati o continuità aziendale.

A quel punto la domanda non è più:

“Funziona?”

Diventa:

“Sono disposto a rispondere di questa soluzione se domani non funziona?”

E cambia completamente il livello di attenzione richiesto.

Forse stiamo usando l’AI dalla parte sbagliata

Se non conosco lo sviluppo software, forse il modo migliore di usare l’AI non è chiederle di sviluppare un software al mio posto.

Forse è più utile chiederle:

“Cosa devo verificare prima di scegliere questo software?”

“Quali domande devo fare al fornitore?”

“Quali rischi di sicurezza devo approfondire?”

“Quali integrazioni devo considerare?”

“Come verifico che i miei dati siano esportabili?”

“Quali SLA dovrei chiedere?”

“Quali domande tecniche posso fare per capire se chi ho davanti conosce davvero la materia?”

Questo è un utilizzo dell’AI che trovo estremamente potente.

Perché non le sto chiedendo di sostituire una competenza che non possiedo.

La sto usando per aiutarmi a capire dove si trova la mia incompetenza.

E per arrivare davanti a chi quella competenza ce l’ha con domande migliori.

Competenza + AI

Questo è il modello che vedo funzionare meglio.

Nel nostro team di sviluppo l’AI velocizza il lavoro.

Aiuta a commettere meno errori.

Permette di analizzare problemi più rapidamente.

Suggerisce alternative.

Controlla.

Ma non decide la direzione al posto dello sviluppatore.

È lo sviluppatore che guida.

La differenza è sostanziale.

Non:

AI al posto della competenza.

Ma:

AI che moltiplica la competenza.

 

Dove mettere lo STOP?

Non credo esista ancora una risposta universale.

Per un piccolo automatismo interno posso accettare molto rischio.

Per un prototipo posso sperimentare.

Per un’applicazione che gestisce dati critici, clienti o processi core il livello cambia completamente.

E probabilmente il vero errore sarebbe arrivare alla fine del progetto e solo allora chiedere a un professionista di verificarlo.

Perché potrebbe scoprire che architettura, database o sicurezza sono stati impostati male.

E a quel punto parte del tempo e del denaro apparentemente risparmiati dovranno essere spesi una seconda volta.

Forse il professionista non deve fare tutto.

Ma deve entrare abbastanza presto da evitare che si costruisca velocemente nella direzione sbagliata.

Le domande che continuo a pormi

Più utilizzo l’AI, meno mi interessa chiedermi semplicemente cosa sia capace di fare.

Le domande che trovo più importanti sono altre:

Sono in grado di verificare ciò che mi sta proponendo?

Conosce davvero tutto il contesto necessario?

Cosa non le ho raccontato?

Come evolverà questa soluzione tra due o tre anni?

Chi controllerà le modifiche future?

Quanto è critica questa applicazione per la mia azienda?

Che cosa succede se sbaglia?

E soprattutto: chi se ne assume la responsabilità?

Non credo che la risposta sia utilizzare meno l’AI.

Credo che dobbiamo imparare a utilizzarla meglio.

Quando possediamo una competenza, usarla per amplificarla.

Quando non la possediamo, usarla per comprendere meglio il problema, preparare le domande e valutare meglio chi quella competenza ce l’ha.

Perché riuscire a fare qualcosa non significa necessariamente saperla fare.

E forse una delle capacità più importanti nell’era dell’Intelligenza Artificiale sarà proprio questa:

capire quando possiamo continuare da soli e quando è il momento di fermarci e dire: da qui in avanti, serve qualcuno che sappia realmente cosa sta facendo.

 

Vuoi capire dove l’AI può davvero creare valore nella tua azienda?

Adottare l’Intelligenza Artificiale non significa semplicemente utilizzare nuovi strumenti. Significa capire dove può migliorare processi e produttività, quali rischi devono essere valutati e dove la tecnologia deve essere affiancata da competenze reali.

In Atik lavoriamo ogni giorno con AI, sviluppo software e sistemi aziendali, con un principio preciso: usare l’Intelligenza Artificiale per amplificare le competenze, non per sostituirle dove sono necessarie.

Contattaci per valutare insieme come integrare l’AI nei processi della tua azienda.