Tre mosse pratiche per la governance dell'AI in cloud: osservabilità, residenza, limiti

Amazon mette a terra tre pattern operativi: metriche locali di Codex che terminano in CloudWatch senza proxy, inferenze di Claude Code confinate a Londra, limiti per utente su AgentCore. Insieme puntano a un’idea semplice: l’adozione enterprise dell’AI si sblocca quando osservabilità, residenza dei dati e controllo dei picchi diventano configurazioni nette, non compromessi o eccezioni.

Perché questi tre strumenti contano

Le squadre che passano dai test all’uso quotidiano chiedono tre certezze: chi usa cosa e quanto; dove restano prompt e risposte; come evitare che pochi account saturino tutto. Amazon risponde con tre mosse pratiche: telemetria locale verso CloudWatch, vincoli di regione a livello di inferenza, rate limiting legato all’identità su un gateway unico. Non sono feature isolate. Sono tasselli di una stessa governance tecnica: visibilità, perimetro, disciplina del traffico.

Osservabilità: metriche locali e vista nativa AWS

Primo tassello: misurare bene, subito, senza introdurre colli di bottiglia. Amazon mostra come inviare le metriche di Codex da ogni workstation direttamente a CloudWatch, senza un proxy centrale nel percorso delle richieste al modello. I client di Codex usano modelli di OpenAI tramite Amazon Bedrock e si autenticano con AWS IAM Identity Center. La telemetria resta sulla macchina dello sviluppatore fino al collector OpenTelemetry; poi viaggia su un canale separato verso CloudWatch.

Sulla workstation gira il collector. Riceve su localhost, aggiunge contesto organizzativo e inoltra all’endpoint regionale OTLP di CloudWatch. Le richieste usano AWS Signature Version 4 per l’autenticazione. Ne risulta una vista nativa di AWS sull’uso di Codex, organizzabile per utente, team, dipartimento, organizzazione o centro di costo.

Questo impianto sposta il controllo vicino alla sorgente. Evita proxy condivisi che intrecciano dati applicativi e telemetria. Mantiene separati i piani: richieste al modello da un lato; metriche OpenTelemetry dall’altro. Così i responsabili misurano uso e affidabilità senza introdurre infrastrutture centrali nel percorso critico delle inferenze.

Residenza delle inferenze: forzare la regione dell’elaborazione

Secondo tassello: il perimetro geografico. Un team AWS ha soddisfatto un requisito netto: tutte le inferenze di Claude Code devono avvenire in eu-west-2, a Londra. La richiesta, i prompt, i completamenti e le elaborazioni intermedie devono restare nella stessa regione. Il caso nasce da un’organizzazione statunitense che impone Londra come unico perimetro geografico per l’inferenza di Claude Code.

Il percorso non è stato lineare. Hanno testato l’endpoint Mantle di Amazon Bedrock e trovato, in quella configurazione, una limitazione che non garantiva l’elaborazione in regione. Gli autori chiariscono che la scelta tra Mantle e Invoke dipende dalla regione operativa e dalla disponibilità dei percorsi descritti. La soluzione adottata usa l’API classica Invoke, un application inference profile per definire il modello e una policy IAM con una condizione sulla regione. La combinazione forza l’elaborazione del modello in eu-west-2 e soddisfa il requisito di residenza dei dati a livello di inferenza.

Il punto qui è dove applicare il vincolo. Non sull’endpoint soltanto, ma nella catena che determina dove il modello elabora. L’accoppiata profilo di inferenza e condizione IAM sposta la garanzia dalla “superficie di rete” alla “decisione di esecuzione”. È un controllo discreto, legabile all’identità e alla regione, riusabile nei flussi che toccano modelli diversi.

Limitare il consumo: rate limiting per identità su AgentCore

Terzo tassello: contenere i picchi. Amazon introduce limiti per utente sul gateway Bedrock AgentCore per evitare che pochi account saturino modelli, agent e servizi a valle durante i picchi. Le policy si applicano all’ingresso unico del traffico e non richiedono modifiche ai sistemi dietro il gateway.

AgentCore opera come gateway AI fully managed e serverless. Fa da punto di ingresso e instrada verso web search gestita, knowledge base gestite, server MCP, modelli di inference, agent (agents as tools e A2A) ed endpoint HTTP. Il nuovo controllo riunisce in un solo punto la definizione dei limiti. Le regole ancorano ogni utente a OAuth o IAM e definiscono come può consumare gli strumenti e i percorsi esposti.

Le metriche disponibili includono richieste al minuto, richieste al secondo, connessioni concorrenti e throughput di token. Le soglie si applicano in modo coerente ai tre target supportati: target MCP, target di inference e target HTTP in passthrough. In pratica, la disciplina del traffico si impone a monte, uniforme per percorsi eterogenei che confluiscono nel gateway.

Questo spostamento del controllo all’ingresso evita soluzioni locali non coordinate. Slega la protezione dei modelli e dei servizi downstream dal loro ciclo di rilascio. Introduce una forma di “budget” per identità che convive con le metriche raccolte e con i vincoli di residenza applicati a valle.

Implicazioni operative e di governance

Messe insieme, le tre mosse disegnano un percorso coerente per portare agenti di coding e modelli in produzione. La telemetria locale produce una vista in CloudWatch per utente e centro di costo senza toccare il percorso delle inferenze. I vincoli di regione, applicati con Invoke, application inference profile e policy IAM, spostano la residenza dei dati dal piano delle intenzioni a quello dell’esecuzione in eu-west-2 nel caso di Claude Code. Il rate limiting per identità su AgentCore stabilisce chi consuma quanto e con che cadenza, in modo uniforme su modelli, agent, MCP e HTTP.

Operativamente, i controlli si distribuiscono su tre punti: workstation, policy di inferenza e gateway. Questo richiede integrazione tra IAM, collector OpenTelemetry e regole di rate limiting. Porta però benefici concreti: misurare l’adozione, rispettare perimetri geografici, preservare la disponibilità durante i picchi. Ogni tassello resta discreto e configurabile: non chiede proxy centralizzati per le metriche; non presuppone che ogni endpoint garantisca la residenza da solo; non impone modifiche ai servizi a valle quando si fissano i limiti.

Per chi guida AI, software e QA, la novità è la traducibilità in policy interne. La vista nativa AWS di Codex consente breakdown per team e costi; il vincolo di regione codifica la residenza al livello dell’inferenza; il gateway impone limiti coerenti per identità. Sono tre leve documentate, applicabili con gli strumenti di piattaforma già usati in azienda.

La prossima verifica, sul campo, sarà incrociare queste leve: metriche di Codex su CloudWatch per calibrare i limiti di AgentCore e, in parallelo, policy IAM che tengono le inferenze nella regione consentita; un trittico che può diventare checklist di audit e runbook di risposta ai picchi, perché ogni controllo vive dove serve: sulla workstation, nella decisione di esecuzione, all’ingresso del traffico.