Perché preparare le domande prima della demo?
Una dimostrazione mostra il sistema nelle condizioni migliori, su esempi scelti da chi lo vende. Le questioni che pesano dopo la firma stanno quasi sempre altrove: nelle condizioni sui dati, nei costi che crescono con l’uso, nella possibilità di cambiare fornitore senza ricominciare da zero. Arrivare all’incontro con una lista scritta permette di confrontare offerte diverse sugli stessi punti e di chiedere che le risposte entrino nel contratto o nei suoi allegati.
Le domande che seguono valgono con un grande fornitore di piattaforme come con un integratore locale che costruisce un agente su misura, e valgono anche per Tribus. Il peso di ciascuna cambia con il progetto. Per un abbonamento standard a un assistente generativo le condizioni non si negoziano, e le domande servono a scegliere tra prodotti e a conservare la documentazione. In un progetto su misura che tocca il gestionale e i dati dei clienti, quasi tutte diventano clausole da scrivere.
Una regola pratica: una risposta data solo a voce, durante una presentazione, va trattata come una risposta che manca.
Cosa succede ai nostri dati?
È il gruppo di domande più importante quando il sistema tratta dati di clienti, dipendenti o informazioni riservate. La prima riguarda l’addestramento: dati, conversazioni e documenti caricati vengono usati per addestrare o migliorare i modelli? Conta che l’esclusione sia scritta nel contratto e valga per impostazione predefinita, senza dipendere da un’opzione che qualcuno deve ricordarsi di disattivare.
La seconda riguarda la conservazione. Per quanto tempo restano richieste, risposte, file caricati, registri di sistema e copie di backup? Cosa succede alla fine del contratto, e in che modo il fornitore conferma la cancellazione? La terza riguarda il luogo: dove sono i server, da dove accede il personale di assistenza e quali garanzie si applicano se i dati escono dall’Unione europea, come previsto dal Capo V del GDPR. Un fornitore con server in Europa può comunque appoggiarsi a servizi o assistenza fuori dall’UE.
Quasi ogni soluzione di AI si appoggia ad altri soggetti: il fornitore del modello, il cloud, a volte servizi di trascrizione o di ricerca. Sono i sub-responsabili. L’art. 28 del GDPR stabilisce che il responsabile non può ricorrervi senza autorizzazione scritta del titolare e che, se l’autorizzazione è generale, deve informarlo delle modifiche e dargli la possibilità di opporsi. Chiedi l’elenco aggiornato e come vieni avvisato dei cambiamenti.
Tutto questo va nel contratto di trattamento previsto dall’art. 28, spesso chiamato DPA. Tra le altre cose deve stabilire che il fornitore tratti i dati solo su istruzione dell’azienda, adotti misure di sicurezza adeguate, cancelli o restituisca i dati al termine del servizio e metta a disposizione le informazioni necessarie per le verifiche. Se un fornitore tratta dati personali per conto dell’azienda e non propone un DPA, non è pronto per quel progetto.
Come è protetto il sistema, e cosa può fare da solo?
Le domande di sicurezza consuete valgono anche qui: come si gestiscono utenti e permessi, se sono disponibili l’accesso con le credenziali aziendali e l’autenticazione a più fattori, quali attività vengono registrate e per quanto tempo, come sono cifrati i dati. In caso di violazione dei dati personali il GDPR stabilisce che il responsabile informi il titolare senza ingiustificato ritardo. Chiedi come avviene la comunicazione, a chi arriva e con quali informazioni. Se il fornitore cita certificazioni, chiedi il certificato e verifica a quali servizi si riferisce.
I sistemi di AI aggiungono domande proprie. Un agente che legge email o documenti può ricevere istruzioni nascoste nel testo che elabora, una tecnica nota come prompt injection. Più il sistema può agire da solo, per esempio inviare messaggi, modificare ordini o scrivere nel gestionale, più conta sapere quali azioni compie senza conferma umana. Chiedi l’elenco delle azioni possibili, con quali permessi, e come si interrompe il sistema se si comporta in modo inatteso.
Nei servizi condivisi tra più clienti, chiedi anche come sono separati i dati della tua azienda da quelli degli altri, compresi gli indici usati per cercare nei documenti.
Chi è fornitore e chi è deployer per l’AI Act?
L’AI Act distingue tra fornitori, che sviluppano o mettono sul mercato un sistema, e deployer, che lo usano sotto la propria autorità. Quasi tutte le PMI sono deployer. La ripartizione va però chiarita quando il sistema è costruito su misura: se un integratore realizza per te un chatbot per il sito su un modello di terzi, chi è il fornitore del sistema? Dalla risposta dipende, per esempio, chi deve far sapere a chi scrive al chatbot che sta interagendo con un’AI, obbligo che il regolamento pone sul fornitore.
L’art. 25 prevede che anche un deployer sia considerato fornitore di un sistema ad alto rischio se vi appone il proprio nome o marchio, se vi apporta una modifica sostanziale o se ne cambia la finalità in modo da renderlo ad alto rischio. Per una PMI il caso concreto riguarda soprattutto gli usi elencati nell’Allegato III, tra cui alcuni sistemi per selezionare o valutare i lavoratori, che avranno obblighi dal 2 dicembre 2027. Se il progetto tocca questi ambiti, chiedi al fornitore come classifica il sistema e quale documentazione ti consegnerà.
Anche fuori dall’alto rischio resta l’art. 4, che chiede a fornitori e deployer di adottare misure per sostenere l’alfabetizzazione AI di chi usa i sistemi. È ragionevole aspettarsi dal fornitore istruzioni d’uso comprensibili, l’indicazione dei limiti noti del sistema e, se serve, un contributo alla formazione delle persone che lo useranno.
Di chi sono risultati, configurazioni e personalizzazioni?
In un progetto di AI l’azienda produce molto più dei testi generati. Ci sono le istruzioni scritte per il sistema, i flussi di lavoro configurati, la base di documenti preparata e indicizzata, gli esempi usati per la messa a punto, il codice delle integrazioni con il gestionale. Il contratto dovrebbe dire chi ne è titolare e cosa l’azienda può portare con sé se cambia fornitore. Una licenza d’uso valida finché dura l’abbonamento è una situazione molto diversa dalla proprietà del codice e delle configurazioni.
Sui risultati generati, la legge 132/2025 ha modificato la legge sul diritto d’autore: sono protette le opere dell’ingegno umano, anche create con l’ausilio di strumenti di AI, purché siano il risultato del lavoro intellettuale dell’autore. Il contratto regola i rapporti tra azienda e fornitore sui risultati, e non può estendere una tutela che la legge non prevede. Chiedi anche se il fornitore offre garanzie nel caso in cui un terzo contesti un risultato come copia di un suo contenuto, e a quali condizioni.
Verifica infine cosa può fare il fornitore con quello che ha imparato dal tuo progetto. Che maturi esperienza è normale; il riuso dei tuoi documenti, delle tue istruzioni o dei tuoi dati per altri clienti va escluso per iscritto.
Come si esce dal contratto senza restare bloccati?
Il lock-in è la dipendenza da un fornitore che rende costoso o impraticabile cambiarlo. Nei progetti di AI ha più livelli: i dati caricati, le configurazioni, le integrazioni e il modello sottostante. Le domande sono semplici. In quale formato posso esportare dati, documenti, storico e configurazioni? In quanto tempo e a quale costo? Il fornitore assiste il passaggio a un altro sistema? Cosa resta conservato dopo la chiusura, e per quanto?
Il Data Act europeo (Reg. UE 2023/2854), applicabile dal 12 settembre 2025, interviene sul passaggio tra servizi di trattamento dei dati come il cloud. Secondo la Commissione, i fornitori di servizi PaaS e SaaS devono rendere disponibili interfacce aperte ed esportare almeno i dati in un formato di uso comune e leggibile da dispositivo automatico; dal 12 gennaio 2027 non possono più addebitare costi di passaggio, compresi quelli per l’uscita dei dati. Se e come queste regole si applichino al singolo servizio di AI va verificato caso per caso, e intanto conviene scrivere le condizioni di uscita nel contratto.
C’è poi la dipendenza dal modello. Molte soluzioni si appoggiano al modello di un altro fornitore, che può essere aggiornato o ritirato. Chiedi se il sistema può funzionare con un modello diverso, come vieni avvisato quando il modello cambia e come si verifica, dopo l’aggiornamento, che le prestazioni restino quelle concordate.
Quanto costa davvero con l’uso reale?
Molti servizi di AI hanno una parte di costo variabile: si paga per richiesta, per quantità di testo elaborato, per documento, per conversazione o per azione dell’agente. In fase di prova i volumi sono bassi e la spesa sembra trascurabile. Con tutto il personale al lavoro, o con un agente che elabora ogni email in arrivo, può cambiare molto. Chiedi una stima costruita sui tuoi volumi reali, con il dettaglio delle voci, e cosa succede se li superi.
Servono anche strumenti di controllo: limiti di spesa impostabili, avvisi al raggiungimento di una soglia, report di consumo per utente o per processo. Verifica come e con quale preavviso possono cambiare i prezzi, e se un aumento del costo del modello sottostante viene ribaltato sul cliente.
Al canone e all’uso si sommano voci che spesso non compaiono nella prima offerta: integrazione con i sistemi esistenti, preparazione dei documenti, formazione, manutenzione delle integrazioni quando cambiano gestionale o modello. Un confronto tra offerte ha senso solo se tutte includono le stesse voci, su un orizzonte di uno o due anni.
Chi risponde quando qualcosa non funziona?
Un sistema di AI può sbagliare anche quando è configurato bene, e prima o poi qualcosa smette di funzionare: un’integrazione dopo un aggiornamento del gestionale, una risposta che peggiora dopo un cambio di modello. Chiedi per iscritto come si apre una richiesta di assistenza, in quali orari e in che lingua, chi la prende in carico e quali tempi di risposta e di risoluzione il fornitore si impegna a rispettare. Tempi che non compaiono nel contratto non lo impegnano.
Nei progetti con più soggetti, per esempio un integratore che usa il modello di un altro fornitore e si collega al tuo gestionale, chiarisci chi è il referente unico e come vengono smistati i problemi. Chiedi anche cosa è incluso nel canone e cosa si paga a parte: aggiornamenti, nuove funzioni, adeguamenti a cambi normativi, interventi sulle integrazioni.
Come si verifica il sistema prima di firmare?
La domanda più utile è anche la più semplice: possiamo provarlo sui nostri casi? Una prova seria usa una ventina di esempi reali dell’azienda, compresi quelli difficili e le eccezioni, e confronta il risultato con quello che fanno oggi le persone. I criteri si decidono prima di iniziare: quanti casi devono risultare corretti senza intervento, quanto tempo richiede il controllo umano, quali errori sono inaccettabili.
Chiedi al fornitore quali metriche propone e come le misura, e verifica che si possano ripetere in modo indipendente, sugli stessi casi, anche dopo il rilascio. Concorda in anticipo cosa succede alla fine della prova: costi, durata e possibilità di fermarsi senza vincoli se i criteri non sono raggiunti. L’articolo su come misurare un progetto pilota di AI spiega come impostare il confronto.
Se un fornitore rifiuta qualsiasi prova sui tuoi dati e propone solo demo sui suoi esempi, anche questo va considerato nella scelta. A volte una prova completa non è possibile, per esempio per vincoli sui dati: si può allora lavorare su dati anonimizzati o su un sottoinsieme, purché sia rappresentativo.
Prenota un incontro