AIUTO ALLA DECISIONE · SCELTA DELLA PIATTAFORMA

Valutare lo strumento sul lavoro, non sulla dimostrazione

La mappa è un’ipotesi di partenza, non una classifica. Separa la rapidità di adozione dal controllo e dalla reversibilità, e va verificata su un lavoro rappresentativo.

01Posizionamento indicativo · da verificare con lo stesso dossier di prova
02Adeguatezza per tipo di lavoro

Un solo vincitore è raramente la risposta giusta. Scegliete un’architettura principale, poi indicate dove una seconda porta un valore reale.

Tipo di lavoroSpazio di lavoroAgente di codiceAgente sul computerArchitettura apertaOrchestrazione
Lavoro di conoscenza correntefortebassomediomediomedio
Sviluppo softwaremediofortebassomediomedio
File e postazione localemediobassofortebassomedio
Prodotto distintivobassomediobassoforteforte

L’unità di valutazione è un compito concluso, non una risposta del modello.

«Quale strumento di IA dobbiamo scegliere?» sembra una domanda di prodotto. In azienda è una decisione di architettura che coinvolge dati, identità, processi, controlli, costi e la capacità di cambiare rotta.

I prodotti non fanno la stessa cosa. Claude e ChatGPT Enterprise coprono il lavoro intellettuale in senso ampio; Claude Code e Codex lavorano nel codice e cambiano il modo di sviluppare software; Kimi Work, pubblicato dalla società cinese Moonshot AI, propone agenti che lavorano sui file locali, nel browser e su compiti ricorrenti; Kletron, il prodotto di agenti sviluppato e gestito da Numezis, coordina più agenti su incarichi operativi. I modelli a pesi aperti, infine, permettono di ospitare tutto in proprio. La risposta giusta dipende dal lavoro da svolgere, non dalla tabella delle funzionalità.

Configuriamo e integriamo questi prodotti ogni giorno: impostazioni, collegamenti con i vostri programmi (in particolare tramite il protocollo MCP), prove, diritti di accesso e controlli in produzione. Conoscere i prodotti conta, ma la decisione di architettura viene prima.

Descrivere il lavoro prima di scegliere il prodotto

Tracciate prima il confine di fiducia attorno al lavoro. Che cosa può leggere il sistema? Che cosa può conservare? Quali strumenti può richiamare? Che cosa può modificare? Dove deve confermare una persona? Quali tracce devono restare disponibili a lavoro concluso?

Queste domande cambiano subito l’elenco dei candidati. Uno spazio di lavoro aziendale è adatto alla redazione e all’analisi; un agente di programmazione ha il suo posto in un repository isolato; un agente che lavora sui file di una postazione si prova in un perimetro molto ristretto; un’architettura aperta si giustifica per un prodotto distintivo, non perché «aperto» sarebbe più sicuro, ma perché l’impresa ha bisogno di controllare aspetti che un prodotto online non rende accessibili.

Tipo di lavoroChe cosa può fare il sistemaChe cosa bisogna dimostrareScelta predefinita ragionevole
Aiutare a redigereLeggere e redigereQualità, rispetto del perimetro dei datiSpazio di lavoro aziendale
Cercare e raccomandareLeggere, confrontare, raccomandareRisposte fondate sulle fonti, diritti di accesso, traccia di chi rileggeSpazio di lavoro o interfaccia di programmazione
SviluppareLeggere il codice, modificare, testare, proporreEsecuzione isolata, rilettura delle modifiche, risultati dei testAgente di programmazione in ambiente isolato
Agire nei programmiRichiamare strumenti, aggiornare sistemiDiritti minimi, verifica, ritorno allo stato precedenteApplicazione orchestrata
Servire clientiRispondere a utenti esterni in grandi volumiEsercizio, monitoraggio, costo unitario, via d’uscitaInterfaccia di programmazione o base controllata

Provare ogni candidato con lo stesso dossier di prova

Le dimostrazioni commerciali mostrano la disinvoltura; un dossier di prova comune mostra ciò che conta per decidere. Stessi compiti, stessi documenti, stessi diritti, stessa griglia di valutazione, stesse ipotesi di costo per ogni candidato. Includete i casi limite: documenti incompleti, istruzioni contraddittorie, contenuti in più lingue, campi riservati, istruzione trappola nascosta in un documento, guasto di uno strumento, richiesta di un’azione irreversibile.

Il dossier produce sei risultati:

  1. Qualità: esattezza, completezza, fedeltà alle fonti, sforzo di rilettura.
  2. Affidabilità: risultati riproducibili, comportamento in caso di guasto o di ritardo.
  3. Controlli: che cosa il sistema rifiuta, che cosa fa confermare, che cosa registra.
  4. Sforzo d’integrazione: identità, connettori, interfacce, ambienti, carico di supporto.
  5. Costo completo: licenze o consumo, messa in opera, rilettura umana, esercizio, uscita.
  6. Reversibilità: che cosa si esporta, che cosa bisognerebbe ricostruire, che cosa diventa una dipendenza.

Non riassumete il dossier in un voto unico. Un candidato può vincere sulla qualità e perdere la decisione perché non rispetta il perimetro dei dati richiesto.

Prima i dati: dove vengono trattati?

Per ogni candidato verificate dove vengono trattati e archiviati i contenuti, per quanto tempo sono conservati, se possono servire a migliorare il servizio, e su quale base giuridica è possibile una comunicazione fuori dalla Svizzera (paese riconosciuto come adeguato, certificazione secondo lo Swiss-US Data Privacy Framework, clausole contrattuali tipo). È un punto di attenzione particolare per Kimi Work: finché il trattamento in Cina o fuori dalla Svizzera e dall’UE non è coperto da garanzie sufficienti, non inseritevi né dati di clienti né dati protetti. La nostra analisi nLPD, AI Act e IA generativa descrive queste regole nel dettaglio.

Quattro architetture tipo

Lo spazio di lavoro gestito (ChatGPT Enterprise, Claude Enterprise, Copilot). La scelta predefinita giusta per un uso ampio all’interno: identità, amministrazione e accesso ai modelli nello stesso posto. In cambio, accettate i limiti del prodotto e dovete verificare come vengono gestiti dati, connettori, conservazione e cambi di modello.

L’interfaccia di programmazione gestita (API di un fornitore di modelli). La scelta giusta per un’applicazione distintiva o un processo controllato: controllate voi l’esperienza, l’orchestrazione, la ricerca documentale e le regole. In cambio, realizzazione ed esercizio sono a vostro carico: un’API non è un servizio completo.

L’agente di programmazione o di postazione di lavoro (Claude Code, Codex, Kimi Work). La scelta giusta quando il lavoro vive in file, in un repository di codice, in un terminale o in un browser. In cambio, la superficie d’azione è più ampia: isolamento, diritti locali, segreti, sessioni del browser e rilettura umana diventano una vostra responsabilità.

L’architettura aperta o ospitata presso di voi. La scelta giusta quando il controllo, il luogo di hosting, la struttura dei costi o la differenziazione giustificano di gestire tutto in proprio. In cambio, non si tratta solo di server: prove dei modelli, aggiornamenti, capacità, sicurezza, risposta agli incidenti e supporto sono a carico vostro.

Una combinazione è spesso razionale, a condizione che i confini siano scritti: lo spazio di lavoro per l’uso corrente a basso rischio, l’agente di programmazione per lo sviluppo, un’interfaccia di programmazione per un processo rivolto ai clienti, un modello aperto solo dove il controllo lo richiede. Un accumulo di strumenti senza confini crea identità doppie, regole sui dati incoerenti e nessun responsabile.

Confrontare il costo per pratica trattata

La domanda non è quasi mai «prezzo per utente contro prezzo per richiesta». Confrontate il costo completo per pratica trattata con successo: piattaforma, consumo, integrazione, preparazione dei dati, prove, rilettura umana, esercizio, modifiche e uscita. Poi confrontatelo con il costo attuale, lavoro rifatto e ritardi compresi. Uno strumento economico per richiesta costa caro per pratica se gli utenti devono correggere la maggior parte dei risultati.

Preparate tre scenari: progetto pilota, volume atteso e scenario difficile (più volume, documenti più lunghi, tasso di successo più basso, cambio di modello, rilettura rafforzata). Lo scopo non è una cifra precisa, ma individuare l’ipotesi che ribalterebbe la decisione.

Mettere per iscritto la decisione e la via d’uscita

Una buona scheda di decisione descrive il contesto, le opzioni, i risultati del dossier di prova, la scelta fatta, i rischi accettati e le condizioni per riesaminarla. Descrive anche l’uscita in cinque righe: formato di esportazione dei dati, elenco delle integrazioni, possibilità di riutilizzare le prove, dipendenze degli utenti e formazioni, tempo stimato per una sostituzione credibile. La si rivede quando cambiano il contratto, il prezzo, il comportamento del modello o l’importanza del processo.

La risposta giusta non è «siamo neutrali rispetto ai fornitori». È «sappiamo perché questa architettura vince per questo lavoro, che cosa accettiamo e quali opzioni ci siamo tenuti aperte».

Come possiamo aiutarvi

La scelta e la configurazione di uno spazio di lavoro per i vostri team rientrano nell’Accompagnamento IA. Il dossier di prova, l’integrazione con i vostri programmi, gli agenti e le architetture su misura rientrano nell’offerta Engineering IA: analisi preliminare da una a tre settimane, poi preventivo vincolante, oppure abbonamento se più progetti si susseguono. Per una PMI che esita tra ChatGPT, Claude, Gemini e Copilot, l’analisi quale scegliere per una PMI è più diretta.