DECISION TOOLKIT · SELEZIONE PIATTAFORMA

Posizionare lo strumento sul lavoro, non sulla demo

La mappa è un’ipotesi iniziale, non un benchmark. Separa la velocità verso il valore da controllo e reversibilità e obbliga a validare la posizione su lavoro rappresentativo.

01Posizionamento indicativo · validare con lo stesso evidence pack
02Fit per archetipo di workflow

Un solo vincitore è spesso la risposta sbagliata. Scegliere un pattern principale e chiarire dove un secondo crea valore materiale.

ArchetipoWorkspaceCoding agentDesktop agentOpen stackOrchestrazione
Broad knowledge workfortefortemediomediomedio
Software deliverymediomediofortefortebasso
Desktop / local workmediobassobassobassoforte
Differentiated productbassobassomedioforteforte

L’unità di valutazione è un workflow completato, non una risposta del modello.

La domanda «qual è il miglior strumento AI?» è quasi sempre sbagliata per un’impresa. Claude Code, OpenAI Codex, ChatGPT Enterprise, Gemini, Mistral, Kimi Work e i modelli aperti incarnano pattern differenti di esecuzione e controllo. La scelta deve partire dal workflow e dall’autorità consentita.

Determinare prima la forma del lavoro

Un workspace chat gestito sostiene il knowledge work con identità e amministrazione comuni. Un coding agent può leggere repository, eseguire comandi e produrre modifiche. Un agente desktop opera vicino a file e sessioni browser autenticate. Un’architettura open-weight trasferisce all’impresa più controllo — e più responsabilità di lifecycle.

Queste categorie non sono intercambiabili. Un confronto di feature nasconde le differenze più importanti.

Pattern di lavoroDomanda architetturale primaria
Assistente enterpriseCome preservare identità, permessi delle fonti e classi di dati?
Coding agentQuale autorità ha su repository, shell, rete e segreti?
Agente desktopQuali file locali, sessioni browser e azioni pianificate sono consentiti?
Applicazione personalizzataCome integrare modello, retrieval, tool, evaluation e operations?
Open-weight / self-hostedL’organizzazione può gestire serving, sicurezza, aggiornamenti e capacità?

Usare sei dimensioni decisionali

1. Dati

Seguite il percorso completo di input, contesto e output. Verificate residenza, retention, training, telemetria, subprocessori, cancellazione e permessi sorgente. «Enterprise» non sostituisce una mappa concreta dei flussi.

2. Integrazione

Considerate identità, API, server MCP, repository, connettori SaaS e sistemi di business. Ogni integrazione amplia il contesto e può ampliare l’autorità del sistema.

3. Sicurezza

Il threat modeling deve produrre controlli: least privilege, isolamento, secret handling, policy di rete, branch protetti, gate umani, logging e revoca immediata. Plugin e server MCP della comunità sono componenti di supply chain, non semplici comodità.

4. Prestazioni

Eseguite benchmark su task rappresentativi. Misurate tasso di completamento, tipi di errore, citazione delle fonti, comportamento dei test, latenza, intervento umano e stabilità con contesto lungo.

5. Economia

Licenze e token sono solo una parte. Il costo totale include integrazione, evaluation, security engineering, change, review, compute, supporto e operations. Una piattaforma più cara può essere più economica se elimina complessità; un’architettura aperta può sembrare conveniente e richiedere più ownership.

6. Reversibilità

Un exit path credibile dipende da dati portabili, evaluation riutilizzabili, contratti standardizzati per i tool, logica di business disaccoppiata e alternative documentate. La reversibilità è una proprietà architetturale concreta.

Confrontare le piattaforme con lo stesso evidence pack

Utilizzate gli stessi task, classi di dati, criteri qualitativi e casi di rischio per tutti i candidati. Documentate configurazione, versione del modello, tool consentiti e intervento umano. Altrimenti confrontate demo, non sistemi.

Un decision record solido contiene:

  1. workflow e risultato desiderato;
  2. confini di dati e autorità;
  3. risultati delle evaluation e failure pattern;
  4. modello d’integrazione e operations;
  5. assunzioni di sicurezza e contrattuali;
  6. costi, dipendenze ed exit path;
  7. decisione, durata di validità e trigger di review.

Il multi-piattaforma può essere corretto — ma non casuale

Piattaforme differenti possono essere adatte a knowledge work, software engineering e inferenza privata. È un’architettura solo se identità, classi di dati, permessi dei tool, evaluation e ownership restano coerenti tra le piattaforme. Altrimenti nasce un portafoglio di standard ombra.

La raccomandazione giusta raramente è «un vincitore per tutto». È un abbinamento motivato tra workflow, autorità, controllo e responsabilità operativa, con un percorso esplicito per rivedere la decisione quando tecnologia o evidenze cambiano.