Gateway AI per agenti di codifica: gestione di endpoint, chiavi, modelli e spesa

Gli agenti di codifica stanno passando da esperimenti individuali per sviluppatori a flussi di lavoro di progettazione a livello di organizzazione. Appaiono all'interno di pannelli di chat IDE, agenti della riga di comando, automazione dei repository, lavori CI, strumenti per sviluppatori partner e bot interni in grado di leggere codice, proporre patch, richiamare strumenti ed eseguire attività in più passaggi. Questa espansione crea un problema di governance: ogni agente può portare un formato endpoint, un modello di credenziali, un selettore di modello, un percorso di utilizzo e un profilo di spesa diversi.

Un gateway AI per la codifica degli agenti offre ai team della piattaforma un punto di controllo API governato tra tali agenti e i fornitori di modelli upstream. Invece di distribuire chiavi grezze del fornitore su laptop, repository, corridori di automazione e integrazioni rivolte ai clienti, l'organizzazione instrada il traffico degli agenti attraverso un livello gestito che centralizza l'autenticazione, l'accesso al modello, l'attribuzione dell'utilizzo, la politica di spesa e il routing del fornitore.

L'obiettivo non è solo quello di far sì che un gateway Cursor AI API, un endpoint AI personalizzato GitHub Copilot o un OpenAI compatibile API per gli agenti di codifica funzionino una volta. L'obiettivo duraturo è fornire ai team di ingegneri un modo ripetibile per adottare gli assistenti di codifica senza perdere il controllo su costi, credenziali, verificabilità, disponibilità dei modelli e rischio operativo.

Cosa fa un agente di codifica API Gateway

Un gateway dell'agente di codifica API si trova tra gli strumenti di codifica e i fornitori di modelli. L'agente invia le richieste a un URL di base controllato dall'organizzazione, solitamente con una chiave downstream emessa dal gateway. Il gateway autentica la chiave, applica la policy, registra i metadati, mappa il modello richiesto su un modello upstream approvato, inoltra la richiesta e restituisce la risposta nel formato previsto dal cliente.

In pratica, il gateway solitamente gestisce diverse responsabilità:

• Autenticazione: emissione di chiavi downstream con ambito per team, repository, ambienti, agenti, partner o classi di automazione.
• Isolamento delle credenziali del fornitore: mantenendo le credenziali del fornitore upstream all'interno dei limiti della piattaforma anziché esporle a ogni macchina dello sviluppatore o processo CI.
• Governance del modello: pubblicazione di nomi di modelli, alias, limiti di contesto, livelli di costo, regole di fallback e supporto endpoint approvati.
• Compatibilità degli endpoint: supporta le API forme utilizzate dagli strumenti di codifica, inclusi completamenti chat, risposte, Anthropic API in stile messaggio, streaming e formati di chiamate agli strumenti dove necessario.
• Telemetria: raccolta di conteggio delle richieste, modello, provider, latenza, utilizzo del token, errori, nuovi tentativi, stime dei costi e metadati di attribuzione.
• Controlli della spesa: applicazione di budget, limiti di tariffa, arresti forzati, avvisi e regole dei criteri prima che i loop degli agenti diventino costosi.
• Supporto per il controllo: preservando una cronologia degli eventi sufficiente per indagare su chiavi trapelate, attività fuori controllo, utilizzo imprevisto del modello e incidenti del provider.

Per una piattaforma aziendale come B2B LLM, questi requisiti si associano direttamente all'accesso unificato API, ai controlli dell'organizzazione, all'analisi dell'utilizzo, alla gestione dei costi, alla governance API-key e alle funzionalità dei Partner API. Il modello gateway è particolarmente importante quando gli agenti di codifica vengono utilizzati da più team o esposti tramite flussi di lavoro di sviluppo rivolti ai partner.

Quali superfici dell'agente di codifica appartengono all'ambito

Il primo errore commesso da molti team è considerare la governance degli agenti di codifica come un'impostazione IDE. Le impostazioni IDE sono importanti, ma sono solo una superficie. Una progettazione utile del gateway inizia con un inventario di dove hanno origine le chiamate del modello API e cosa può fare ciascuna superficie.

IDE e agenti editor

Gli assistenti integrati nell'editor includono strumenti come Cursor, integrazioni di endpoint personalizzati VS Code, Cline ed estensioni simili. Questi strumenti spesso supportano chiavi API personalizzate o sostituzioni dell'URL di base, ma il loro comportamento è diverso. Alcune funzionalità possono utilizzare endpoint personalizzati solo per la chat, mentre il completamento delle schede o le attività di utilità possono continuare tramite servizi integrati. Altri supportano provider compatibili con OpenAI ma richiedono formati di percorso, comportamenti di streaming o risposte all'elenco dei modelli specifici.

Per la governance, le domande chiave riguardano quali funzionalità instradano effettivamente attraverso il gateway, quale identità è collegata alle richieste e se gli utenti possono ignorare l'endpoint approvato con la propria chiave del provider.

CLI agenti e strumenti di sviluppo locale

Gli agenti della riga di comando come gli strumenti in stile Codex, Claude Code, OpenCode e altri agenti terminale possono supportare variabili di ambiente, file di configurazione del provider o definizioni di provider di modelli personalizzati. Alcuni possono puntare a un URL di base compatibile con OpenAI; altri possono utilizzare uno stile Risposte API o uno stile Anthropic Messaggi API. CLI Gli agenti possono anche interagire con file, comandi shell, credenziali locali, gestori di pacchetti e risorse di rete, quindi il gateway del modello è solo una parte del confine di controllo.

Bot del repository e flussi di lavoro CI

L'automazione del repository può generare richieste pull, rivedere differenze, riepilogare problemi, aggiornare la documentazione o eseguire test. Questi flussi di lavoro spesso richiedono credenziali dell'account di servizio, attribuzione a livello di repository, budget più rigidi e percorsi di controllo più chiari rispetto all'utilizzo ad hoc da parte degli sviluppatori. Una chiave condivisa per tutti gli agenti CI rende difficile la risposta agli incidenti e l'allocazione dei costi. Le chiavi con ambito repository o flusso di lavoro offrono ai team della piattaforma un raggio di azione più pulito.

Strumenti per sviluppatori rivolti a partner e clienti

Alcune aziende espongono funzionalità di sviluppo assistito dall'intelligenza artificiale a partner, clienti o utenti interni della piattaforma. In questo scenario, anche il gateway diventa parte di un limite di provisioning e fatturazione. L'organizzazione potrebbe aver bisogno di chiavi separate per cliente, area di lavoro, ambiente del prodotto o applicazione del partner. È qui che le funzionalità dei partner API e i flussi di lavoro automatizzati del ciclo di vita chiave diventano importanti dal punto di vista operativo.

OpenAI-Compatibile non significa universalmente compatibile

Molti strumenti di codifica pubblicizzano il supporto per un URL di base OpenAIcompatibile API o personalizzato. Questo supporto è prezioso perché riduce il lavoro di integrazione, ma dovrebbe essere trattato come un contratto di compatibilità che necessita di test, non come una garanzia che qualsiasi gateway funzionerà con qualsiasi agente.

Ci sono diversi motivi. Alcuni client chiamano Completamenti chat, mentre altri utilizzano Risposte. Alcuni supportano Anthropic API in stile Messaggi. Alcuni richiedono lo streaming in un particolare formato di evento. Alcuni si aspettano elenchi di modelli, output strutturato, chiamate di strumenti, input di immagini, incorporamenti o memorizzazione nella cache del contesto. Un client può anche costruire URL in modo diverso a seconda che l'URL di base includa /v1. Anche le intestazioni di autenticazione, la gestione del token di connessione, il comportamento dei tentativi e l'analisi degli errori possono variare.

Una matrice di compatibilità pratica dovrebbe testare ciascun client rispetto a ciascun tipo di endpoint:

• Completamenti chat
• Risposte
• Anthropic Richieste in stile messaggio
• Streaming e risposte parziali
• Formati di chiamata di strumenti e chiamate di funzioni
• Uscita strutturata
• Input immagine o contesto multimodale
• Incorporamenti, se il flusso di lavoro di codifica utilizza la ricerca o il recupero
• Elenco e verifica dei modelli
• Gestione della lunghezza del contesto
• Limite di velocità e comportamento della risposta agli errori

I team che valutano un accesso OpenAImultimodello più ampio APIcompatibile dovrebbero prestare particolare attenzione ai client degli agenti di codifica perché tendono a utilizzare streaming, chiamate a strumenti, finestre di contesto di grandi dimensioni, tentativi e cicli di lunga durata in modo più aggressivo rispetto ai semplici prompt dell'applicazione.

Dove dovrebbe trovarsi il confine del gateway

Il gateway governa il traffico del modello API. Non deve essere confuso con l'intero modello di sicurezza per gli agenti di codifica.

Un agente di codifica può influenzare diversi piani di controllo separati: richieste di modelli, letture e scritture di file, autorizzazioni del repository, accesso alla shell, MCP chiamate agli strumenti, automazione del browser, segreti locali, installazione di pacchetti, uscita dalla rete e credenziali di distribuzione. Un gateway AI può decidere se una richiesta di modello è consentita, quale modello la riceve, quanto può costare e come viene attribuita. Da solo, non può impedire a un agente di leggere un file locale, eseguire un comando di shell o invocare uno strumento esterno se tali funzionalità sono concesse altrove.

Questo confine è importante nelle revisioni dell'architettura. I team della piattaforma dovrebbero posizionare il gateway davanti all'accesso del fornitore di modelli, quindi associarlo ai controlli adiacenti:

• Criterio IDE: estensioni approvate, impostazioni gestite, configurazione endpoint personalizzata e restrizioni sulle chiavi locali.
• Gestione dei segreti: nessuna chiave grezza del provider nelle macchine degli sviluppatori, nei repository, nei log CI o nei file di configurazione dell'agente.
• Governance del repository: protezioni dei rami, regole del proprietario del codice, requisiti di revisione delle richieste pull e autorizzazioni di automazione.
• Sandbox: limiti per l'esecuzione della shell, l'accesso ai file, le installazioni dei pacchetti e l'uscita dalla rete.
• MCP e governance degli strumenti: server approvati, credenziali con ambito, audit trail e gate di approvazione per operazioni sensibili.
• Osservabilità: telemetria del gateway combinata con repository, CI e log eventi di sicurezza.

Il risultato è un modello di controllo a più livelli. Il gateway gestisce la governance API. I controlli della piattaforma circostanti gestiscono ciò che l'agente può fare con codice, strumenti, file e infrastruttura.

Progettazione delle credenziali: utilizza chiavi downstream con ambito

Un gateway agente di codifica efficace utilizza un modello di credenziali a due livelli. Le chiavi del provider upstream vengono archiviate e ruotate all'interno del gateway o dell'account della piattaforma. Sviluppatori, agenti, processi CI, partner e flussi di lavoro di automazione ricevono chiavi downstream con ambito, osservabili e revocabili.

Le chiavi downstream dovrebbero essere progettate in base alla proprietà e al raggio di diffusione. È facile iniziare con un'unica chiave condivisa per tutti gli agenti di codifica, ma crea problemi immediati: i costi non possono essere allocati in modo accurato, le credenziali trapelate influiscono su ogni flusso di lavoro, l'abuso non può essere isolato e la rotazione delle chiavi può interrompere team non correlati.

Ambiti migliori includono:

• team o unità aziendale
• repository o gruppo di repository
• ambiente, ad esempio sviluppo, gestione temporanea o automazione della produzione
• tipo di agente, ad esempio chat IDE, CLI agente, revisore CI o bot di documentazione
• flusso di lavoro, ad esempio revisione delle richieste pull, generazione di test, assistenza per la migrazione o progettazione dell'assistenza clienti
• identificatore del cliente o del partner per strumenti per sviluppatori esterni

Anche l'identità dovrebbe essere modellata con attenzione. L'utente IDE non è sempre il proprietario della fatturazione. Il proprietario del repository non è sempre il proprietario del rischio. Un flusso di lavoro CI può agire per conto di un team, prodotto o cliente. Il gateway deve consentire metadati della richiesta che separino l'identità dell'utente, l'identità dell'agente, l'identità del repository, l'ambiente, il flusso di lavoro e il proprietario della fatturazione.

Ciò è strettamente correlato alla LLM API gestione delle chiavi, ma gli agenti di codifica aggiungono ulteriore pressione perché le chiavi spesso appaiono nei file di configurazione locali, nelle impostazioni delle estensioni, negli ambienti shell e nei runner di automazione.

Cataloghi dei modelli e policy sugli alias

Gli agenti di codifica necessitano di nomi di modelli stabili. Gli sviluppatori non vogliono che la configurazione di ogni strumento cambi quando un fornitore rilascia una nuova versione del modello o quando l'approvvigionamento modifica la disponibilità del fornitore. I team della piattaforma, tuttavia, devono controllare quale modello upstream viene effettivamente utilizzato, quali tipi di endpoint sono supportati e a quale livello di costo appartiene ciascun modello.

Un catalogo di modelli regolamentati risolve questa tensione. Il gateway può esporre alias approvati come un modello di codifica generale, un modello di revisione rapida, un modello di documentazione a basso costo o un modello di migrazione ad alto contesto. Dietro ogni alias, la piattaforma definisce il provider upstream, la versione del modello, il supporto dell'endpoint, il limite del contesto, il livello di costo, la policy di fallback e la tempistica di deprecazione.

La policy alias necessita del controllo del ciclo di vita. La deriva degli alias non sicuri può modificare il costo, la latenza, la qualità dell'output, il comportamento dello strumento o la compatibilità dell'output strutturato senza che gli sviluppatori se ne accorgano. Per l'automazione del repository di produzione, le modifiche agli alias dovrebbero essere annunciate, testate e verificabili. In alcuni casi, i team potrebbero aver bisogno di versioni di modelli bloccati per flussi di lavoro regolamentati, valutazioni ripetibili o progetti di migrazione sensibili.

Telemetria e attribuzione dell'utilizzo

La telemetria degli agenti di codifica dovrebbe rispondere a domande operative pratiche: quali team utilizzano gli agenti, quali repository generano la maggior parte del traffico, quali modelli determinano i costi, dove le richieste falliscono e quali flussi di lavoro creano cicli o tentativi lunghi. I dashboard dei fornitori raramente forniscono un'attribuzione sufficiente a livello aziendale perché generalmente vedono gli account dei fornitori e le chiavi API, non la struttura interna di un'organizzazione tecnica.

Come minimo, la telemetria del gateway dovrebbe acquisire:

• chiave downstream, team, repository, ambiente, flusso di lavoro e nome dell'agente
• alias del modello, provider upstream e versione del modello upstream
• conteggio delle richieste, token di input, token di output, token memorizzati nella cache ove disponibili e dimensione del contesto
• latenza, stato di completamento dello streaming, classe di errore, numero di tentativi e decisione di fallback
• stima dei costi al momento della richiesta e costo stabilito dopo la riconciliazione del fornitore
• decisioni politiche, come l'accesso negato al modello o il taglio del budget

La telemetria deve rispettare la privacy. Per impostazione predefinita, i prompt completi, i file di origine, le differenze, gli output degli strumenti, i segreti e il contenuto del repository non devono essere registrati. È possibile rispondere alla maggior parte delle domande operative con metadati, conteggi di token, identificatori di modello, dettagli di errore e diagnostica limitata. Quando è necessaria una registrazione più approfondita dei contenuti per il debug, questa dovrebbe essere esplicita, limitata nel tempo, controllata dall'accesso e redatta ove possibile.

Le convenzioni di intelligenza artificiale generativa di OpenTelemetry sono utili come riferimento di progettazione perché incoraggiano attributi indipendenti dal fornitore pur consentendo dettagli specifici del fornitore. Il principio importante è la normalizzazione senza appiattire i campi necessari per eseguire il debug del comportamento del client reale.

Controlli della spesa per gli agenti di codifica

Gli agenti di codifica possono spendere in modo diverso rispetto alle normali applicazioni di chat. Un utente di chat umana può inviare alcuni suggerimenti. Un agente può caricare un contesto di repository di grandi dimensioni, richiamare strumenti, riprovare passaggi non riusciti, eseguire attività parallele, richiedere lunghe tracce di ragionamento o eseguire cicli tra file fino al completamento di un obiettivo. Ciò rende insufficiente il reporting post-hoc.

I controlli efficaci del gateway combinano stima, applicazione, avvisi e riconciliazione. La politica di budget dovrebbe applicarsi a diversi livelli: chiave, utente, team, repository, ambiente, cliente, partner e account globale. Alcuni limiti dovrebbero essere avvisi soft. Gli altri dovrebbero essere fermate difficili.

I controlli utili includono:

• liste consentite modello per chiave o flusso di lavoro
• token di input e output massimi
• tasso massimo di richieste e richieste simultanee
• massimi di costo per richiesta
• budget giornalieri, settimanali o mensili
• budget riservato per lavori di lunga durata
• comportamento limite per budget esauriti
• avvisi prima dell'esaurimento del budget
• cancelli di approvazione per modelli costosi o flussi di lavoro sensibili

Il corretto comportamento di interruzione dipende dal flusso di lavoro. I controlli fail-close impediscono spese fuori controllo ma possono interrompere lunghe attività di codifica. Il comportamento di apertura in caso di errore preserva il flusso degli sviluppatori ma può creare fatture a sorpresa. L'automazione della produzione, i flussi di lavoro rivolti ai partner e le funzionalità fatturate al cliente in genere richiedono controlli più severi rispetto alla chat esplorativa dell'IDE di un singolo sviluppatore.

Per una pianificazione più ampia, i team possono abbinare l'applicazione del gateway a pratiche di gestione dei costi LLM quali proprietà del budget, previsione, rilevamento di anomalie e revisioni del mix di modelli.

Modello di implementazione per i team della piattaforma

Un'implementazione affidabile di solito segue una sequenza anziché un passaggio una tantum.

1. Client e flussi di lavoro dell'inventario

Elenca gli agenti di codifica in uso o in fase di valutazione. Includi casi d'uso di endpoint personalizzati Cursor, GitHub Copilot, endpoint personalizzati VS Code, CLI in stile Codex, Claude Code, Cline, OpenCode, agenti CI, bot di repository interni e integrazioni dei partner. Per ognuno, registra i tipi di endpoint supportati, il comportamento dell'URL di base, il metodo di autenticazione, la configurazione del modello, il supporto dello streaming e quali funzionalità possono utilizzare chiavi personalizzate.

2. Definire la matrice di compatibilità dell'endpoint

Esegui test del contratto per ciascun cliente. Conferma la forma dell'URL, la costruzione del percorso, la gestione del token di connessione, l'elenco dei modelli, l'analisi dello streaming, la serializzazione delle chiamate allo strumento, la gestione degli errori e il comportamento dei tentativi. Testare sia le richieste riuscite che quelle fallite. Gli errori di streaming dopo l'invio delle intestazioni di risposta meritano un'attenzione speciale perché alcuni agenti si bloccheranno o riproveranno eccessivamente.

3. Crea ambiti chiave e requisiti di metadati

Decidi in che modo le chiavi downstream verranno mappate a team, repository, ambienti, flussi di lavoro, corsi di automazione, clienti o partner. Richiedere i metadati della richiesta laddove il client può fornirli. Laddove il cliente non può fornire direttamente metadati avanzati, utilizza chiavi separate o mappatura lato gateway per preservare l'attribuzione.

4. Pubblica il catalogo dei modelli

Esponi gli alias dei modelli approvati con un chiaro supporto per endpoint, limiti di contesto, livelli di costo, casi d'uso consigliati e comportamento di riserva. Gli sviluppatori dovrebbero sapere prima che una richiesta fallisca se un modello è disponibile per un determinato agente e tipo di endpoint.

5. Aggiungi budget e limiti prima del lancio su vasta scala

Inizia con limiti conservativi per i test iniziali, quindi ottimizzali con dati di utilizzo reali. Includere arresti drastici per cicli fuori controllo, modelli ad alto costo e automazione della produzione. Aggiungi avvisi che raggiungono il team proprietario, non solo il team della piattaforma centrale.

6. Implementazione in base al livello di rischio

Una buona sequenza prevede prima gli agenti di documentazione di sola lettura, poi gli agenti di codifica non di produzione, quindi l'automazione del repository, quindi i flussi di lavoro che influiscono sulla produzione e le funzionalità rivolte ai partner. Ogni fase dovrebbe dimostrare la telemetria, l'attribuzione, i controlli del budget e le procedure per gli incidenti prima che la fase successiva espanda l'accesso.

Crea, acquista o utilizza una piattaforma gestita

Le organizzazioni possono creare il proprio gateway, eseguire un proxy open source, utilizzare una piattaforma multimodello gestita o combinare approcci. La scelta giusta dipende dalla capacità tecnica, dai requisiti di conformità, dal mix di fornitori, dall'urgenza delle funzionalità e dalle aspettative di supporto.

Un gateway personalizzato può corrispondere perfettamente alle policy interne, ma diventa un servizio fondamentale della piattaforma. Richiede alta disponibilità, controllo dell'accesso amministrativo, rotazione segreta, manutenzione dell'integrazione del provider, lavoro di compatibilità API, riconciliazione dei costi, policy di registrazione e risposta agli incidenti. L'onere aumenta man mano che i team aggiungono più clienti, fornitori e tipi di endpoint.

Un gateway esistente o una piattaforma gestita può ridurre tale carico operativo, soprattutto quando supporta già accesso unificato API, controlli dell'organizzazione, analisi, gestione dei costi e governance chiave. La valutazione dovrebbe comunque essere concreta. Chiedi quali tipi di endpoint sono supportati, come funzionano gli alias dei modelli, come viene definito l'ambito delle chiavi downstream, quali dati di telemetria sono esportabili, come vengono applicati i budget e cosa succede durante le interruzioni del provider o gli errori di streaming parziali.

La domanda di valutazione più importante non è se la piattaforma può inoltrare una richiesta. Dipende dalla capacità di governare il traffico degli agenti di codifica nel modo in cui opera effettivamente la tua organizzazione.

Errori comuni da evitare

• Trattare OpenAI la compatibilità solo come una modifica dell'URL di base. È ancora necessario testare il tipo di endpoint, il formato del percorso, lo streaming, l'elenco dei modelli e le chiamate agli strumenti.
• Utilizzo di una chiave condivisa per ogni agente. Le credenziali condivise distruggono l'attribuzione e rendono difficili la rotazione, il contenimento e la proprietà dei costi.
• Consentire agli agenti di scegliere qualsiasi modello. L'accesso illimitato al modello può creare problemi di costi, latenza, qualità e gestione dei dati.
• Registrazione del contenuto del codice per impostazione predefinita. I metadati sono generalmente sufficienti per le operazioni; prompt, differenze, segreti e output degli strumenti richiedono regole sulla privacy più rigide.
• Ignorando gli errori parziali di streaming. Gli agenti possono bloccarsi, riprovare o corrompere lo stato dell'attività quando gli errori di streaming non vengono gestiti in modo prevedibile.
• Si presuppone che il gateway copra i rischi della shell e del repository. La policy del modello API è separata dall'accesso ai file, dall'esecuzione dei comandi, dagli strumenti MCP e dalle autorizzazioni del repository.
• Basamento solo sui dashboard dei fornitori. I rapporti sulla spesa a livello di fornitore raramente assegnano i costi per team, repository, cliente, ambiente o flusso di lavoro.
• Modifica degli alias senza controlli. La deriva degli alias del modello può modificare silenziosamente il comportamento nell'automazione della produzione.
• Implementazione dell'applicazione prima dell'abilitazione degli sviluppatori. I team hanno bisogno di esempi testati, indicazioni sui modelli, passaggi per la risoluzione dei problemi e percorsi di escalation.

Conclusione: rendere governabili gli agenti di codifica prima che diventino infrastrutture

Gli agenti di codifica stanno rapidamente diventando parte della toolchain di progettazione. Una volta visualizzati negli IDE, nelle CLI, nei job CI, nei bot di repository e negli ambienti dei partner, le chiavi dei provider non gestiti e le impostazioni degli endpoint ad hoc smettono di essere sostenibili.

Un gateway AI durevole per gli agenti di codifica offre alle aziende un punto di controllo per compatibilità endpoint, chiavi con ambito, cataloghi di modelli, telemetria, controllo dei costi e risposta agli incidenti. Le migliori implementazioni sono esplicite riguardo alla compatibilità del client, attente all'ambito delle credenziali, disciplinate riguardo agli alias dei modelli, attente alla privacy nella telemetria e realistiche riguardo al confine tra la governance del modello API e la sicurezza più ampia dell'agente.

Per i leader tecnici e i team della piattaforma, il passaggio pratico successivo consiste nell'inventariare le superfici degli agenti, testare i contratti degli endpoint, emettere chiavi downstream con ambito, pubblicare un catalogo di modelli approvati e applicare controlli del budget prima di espanderne l'utilizzo. Ciò trasforma l'adozione degli agenti di codifica da una raccolta di eccezioni strumento per strumento in una funzionalità della piattaforma governabile.