Come lavoriamo,
per ogni offerta.

L'inquadramento in SDEN non è una call di discovery. È un'indagine strutturata che produce un enunciato di problema scritto che nomina il vero compito che il software deve svolgere, un'architettura e un log delle decisioni che spiega le scelte tecniche che raccomandiamo (e le alternative che abbiamo considerato), e un registro dei rischi che classifica ciò che potrebbe andare storto per sfruttabilità e impatto sul business. Per il lavoro sull'IA, va oltre: una lettura onesta della fattibilità (è un problema che un modello può risolvere in modo affidabile, o un motore a regole travestito da IA?), un trade-off build-or-buy rispetto alle soluzioni già pronte, e un esame se i tuoi dati sono davvero pronti ad alimentare un modello. La fase termina con una raccomandazione go / no-go che siamo pronti a difendere davanti al tuo consiglio.

Poniamo le domande che gli altri fornitori saltano. Chi è il decisore responsabile dalla tua parte? Com'è il lavoro per l'utente il giorno dopo il lancio, e non durante la demo? Quali dati crea il prodotto, dove risiedono e chi ha il diritto di vederli, e dove si collocano nei livelli di rischio del Regolamento europeo sull'IA? Soprattutto: cosa significa "buono", misurato? Definiamo i criteri di valutazione qui, in prima fase, perché "funziona" sia un numero su cui ci siamo accordati anziché un'impressione alla demo. La fase è pagata, inquadrata nel tempo e breve, di norma da una a tre settimane a seconda dell'ambito.

Una demo è un video. Un prototipo è qualcosa che l'utente può davvero usare, sulla vera forma dei dati, sullo stack esatto che consegneremo in produzione. La seconda fase consegna quest'ultimo. Il team progetta i percorsi essenziali, costruisce un prototipo interattivo per i cammini più a rischio (quelli che determinano se il prodotto è usabile, non quelli che determinano se è bello), e li valida su dati reali e con utenti reali prima che venga posata una sola riga di codice di produzione.

Per l'IA, è qui che si prendono e si registrano le scelte gravide di conseguenze: quale modello, e perché; il retrieval aumentato (RAG) anziché il fine-tuning anziché un semplice prompt; una sola chiamata anziché un agente; e il budget di costo e di latenza entro cui ciascun approccio deve stare. Propendiamo per la tecnologia noiosa sotto l'IA (framework, database e hosting che la comunità ha già debuggato su scala) e nominiamo la ragione di ogni scelta. La fase progetta anche il banco di valutazione: il set di test valutati che ci dirà, in automatico e a ogni modifica, se l'IA migliora o peggiora. Produce il prototipo, un design system (token, componenti, baseline di accessibilità) e questo piano di valutazione e di test per la fase di produzione.

Lo sviluppo in SDEN si svolge in iterazioni di due settimane, con una versione funzionante alla fine di ciascuna. Ogni pull request è revisionata da un secondo ingegnere prima del merge; la barriera di merge esegue la suite di test, la suite di valutazioni della seconda fase, gli analizzatori di sicurezza (SCA, SAST, rilevamento dei segreti) e il type checker. La protezione dei branch è attiva, i commit firmati sono attivi, e nessun ingegnere, nemmeno il più esperto, può aggirare i check. Il risultato è una base di codice dove il secondo ingegnere che legge un file lo capisce già, e dove una modifica che degrada in silenzio l'IA fa fallire la continuous integration anziché arrivare in produzione.

L'hardening è la parte che la maggior parte dei fornitori salta. È il lavoro che trasforma "gira" in "gira in produzione per i prossimi tre anni". Per l'IA, significa guardrail sugli input e sugli output, tetti di costo perché un ciclo impazzito non possa rovinare la funzionalità, e una revisione di sicurezza contro la prompt injection e l'OWASP LLM Top 10, oltre all'OWASP Top 10 e al livello ASVS pertinente. Include anche i test di carico contro i profili di traffico attesi, i test di caos sui modi di guasto che il registro dei rischi ha segnalato in prima fase, oltre alla clausola di assenza di debito tecnico: non consegneremo codice per cui non saremmo disposti a ricevere un alert alle 3 del mattino. Se una scadenza forza una scorciatoia, la scorciatoia atterra nel tracker dei problemi come un P0, e viene ripagata prima che arrivi la prossima funzionalità. Documentiamo esplicitamente questa disciplina nella nostra postura di ingegneria della sicurezza.

La consegna è progressiva. La prima messa in produzione atterra dietro un feature flag, per un solo tenant o una piccola coorte di utenti. Monitoriamo gli SLO (e, per l'IA, i numeri di qualità e di costo) contro traffico di produzione reale durante una finestra di osservazione definita, poi allarghiamo all'audience completa una volta che i dati confermano che il sistema si comporta come previsto. La messa in produzione non è un evento da calendario: è un cambio di stato misurabile.

Ciò che consegniamo con la release è ciò che rende il progetto duraturo: un runbook per ogni attività operativa, una dashboard di monitoraggio che espone gli SLO che ci siamo impegnati a rispettare oltre al comportamento dell'IA in produzione (qualità, deriva, tasso di allucinazione e spesa, non solo la disponibilità), un piano di reperibilità per gli incidenti che il registro dei rischi ha anticipato, un template di risposta agli incidenti, e una documentazione scritta per il prossimo ingegnere che entrerà nel tuo team. Elemento cruciale, la consegna trasferisce l'IA stessa: i prompt, la suite di valutazioni e i guardrail, affinché il tuo team possa modificare il sistema in sicurezza, e non solo tenerlo acceso. I progetti SDEN non finiscono alla messa in produzione: si attenuano. Ci impegniamo a una finestra di supporto definita dopo il lancio (di norma da tre a sei mesi, calibrata sul progetto) durante la quale gestiamo il sistema insieme al tuo team, e durante la quale si trasferisce la conoscenza operativa, non solo il codice.