Tradurre un obiettivo di business in una specifica verificabile

Un requisito di business dichiara un risultato — ridurre il tempo di prima risposta, chiudere più pratiche con lo stesso organico — e non dice niente su modello, latenza o token. Il lavoro di traduzione produce due famiglie separate, e conviene tenerle separate anche nei documenti: i requisiti funzionali (cosa fa il sistema, con quale accuratezza) e quelli infrastrutturali (quanto regge, dove gira, sotto quali vincoli legali).

Il requisito funzionale diventa reale solo quando è misurabile, e in un’applicazione Claude la sua forma è un set di valutazione. La guida alla scelta del modello mette la costruzione dei benchmark specifici al caso d’uso come primo passo, prima del confronto fra modelli: senza un set che rispecchi la distribuzione reale dei casi — inclusi input irrilevanti, input lunghissimi e richieste ambigue su cui due revisori umani non concorderebbero — «quale modello è il migliore» resta un’opinione. Il modo tipico di sbagliare è scrivere il criterio di accettazione come «le risposte devono essere buone»: scrivilo come una soglia su un insieme di casi nominati.

I tre numeri non funzionali che decidono l’architettura

Throughput, latenza tollerata e costo per attività completata: se restano impliciti, riemergono come riprogettazione.

Il throughput non è «richieste al secondo». I limiti sono su tre dimensioni per classe di modello — richieste al minuto (RPM), token di input al minuto (ITPM), token di output al minuto (OTPM) — e quella che salta per prima raramente è quella che avevi in mente. Un dettaglio cambia il dimensionamento: «For most Claude models, only uncached input tokens count toward your ITPM rate limits.» Un prompt di sistema lungo e stabile, messo in cache, smette in gran parte di consumare capacità di input:

limite ITPM nominale   2.000.000 token/min
cache hit rate         80%
input effettivo       10.000.000 token/min  (2M non in cache + 8M letti da cache)

Il caching quindi non è solo una leva di costo: è una leva di capacità, e va messo nel dimensionamento.

La latenza decide la modalità di chiamata. Se qualcuno aspetta davanti a uno schermo serve lo streaming; se nessuno aspetta, il requisito corretto non è «veloce» ma «entro 24 ore», che è la finestra della Message Batches API e costa la metà. Trattare la latenza come binaria — realtime o niente — è il modo più comune di pagare il doppio senza guadagnare nulla.

Il costo, infine, va espresso per attività completata e non per token. Un modello più caro per token che risolve il compito al primo tentativo può costare meno di uno economico che ne consuma tre.

Dove gira l’inferenza: il requisito che arriva dal legale

Conformità e residenza dei dati non sono un capitolo separato: sono ciò che restringe le piattaforme candidate. Sull’accordo di zero data retention la documentazione è netta: «Under a ZDR arrangement, Anthropic does not store customer prompts or responses at rest after the API response is returned.» La HIPAA readiness segue una strada diversa — cifratura, controlli di accesso e audit lungo tutto il ciclo di vita del dato invece della cancellazione immediata — e la documentazione è esplicita: se tratti PHI serve quella, non serve anche ZDR. Alcune superfici sono escluse per costruzione: Claude Managed Agents è stateful, le sessioni conservano la cronologia e lo stato del sandbox lato server, e per questo non rientra né in ZDR né in un BAA HIPAA.

Poi c’è il canale. API di prima parte, Amazon Bedrock, Google Cloud, Microsoft Foundry non sono lo stesso prodotto con URL diverse. Su Amazon Bedrock e Google Cloud il responsabile del trattamento è il cloud provider, non Anthropic, e le piattaforme gestite dai partner fissano i propri calendari di ritiro dei modelli: lo stesso identificativo di modello può essere attivo su una e già ritirato sull’altra. Sull’autenticazione, un requisito del tipo «nessun segreto statico nella CI» ha una risposta precisa: la Workload Identity Federation scambia un JWT OIDC del tuo identity provider con un token Anthropic di breve durata. Con una trappola operativa da mettere subito nel runbook: ANTHROPIC_API_KEY sta sopra la federazione nella precedenza delle credenziali, quindi una chiave dimenticata nell’ambiente la mette in ombra in silenzio.

Il requisito che si scopre tardi: la piattaforma toglie funzionalità

Qui sta l’errore che costa una riprogettazione. La piattaforma viene scelta per motivi di perimetro o di contratto, e solo dopo si scopre che una funzionalità data per scontata non esiste lì. Su Claude in Amazon Bedrock non sono supportati structured outputs, Files API e sorgenti URL, i tool eseguiti dal server (code execution, web search, web fetch), il connettore MCP e gli endpoint Message Batches, Models e Admin.

Rileggi le due sezioni precedenti con questa lista in mano. Se il piano poggiava sul batch al 50% per il carico notturno e sugli structured outputs per l’integrazione a valle, «lo mettiamo su Bedrock così restiamo dentro il perimetro AWS» non è una scelta infrastrutturale neutra: cancella due requisiti funzionali già approvati.

Il metodo che regge è banale e quasi nessuno lo applica: una matrice con una riga per requisito e una colonna per piattaforma candidata, compilata verificando alla fonte la pagina della piattaforma — non a memoria, perché queste tabelle di supporto cambiano di mese in mese.