Model routing: il modello che paghi può non essere quello che esegue la richiesta e le conseguenze legali

Cosa è accaduto

Negli ultimi sviluppi del mercato dell'inferenza, alcune piattaforme hanno introdotto routing a livello di richiesta, fallback su modelli alternativi e distribuzione di pesi quantizzati: il risultato è che il nome del modello passato in chiamata può non corrispondere al motore che effettivamente ha generato la risposta. Questo fenomeno è già osservabile in casi concreti citati dalle fonti: Anthropic restituisce nel response object il modello che ha effettivamente risposto quando avviene una sostituzione; Cursor ha lanciato Router, un classificatore addestrato su oltre 600.000 richieste live che indirizza ogni query al modello ritenuto più appropriato (con report di risparmi del 30–50% per alcuni early-access); OpenRouter segnala invece che alcuni provider servono pesi quantizzati, con risultati diversi e senza tracce nei log utente.

Perché è importante

La frammentazione dell'identità del modello su tre assi — substitution (sostituzione con architettura/weights diversi), degradation (stessa identità servita a precisione ridotta) e drift (stessi nomi che puntano a pesi aggiornati senza versioning) — mette in discussione garanzie contrattuali, trasparenza e possibilità di autenticare l'origine di output generati da AI. Contratti, schede modello e artefatti di compliance spesso fanno affidamento su nomi e versioni; se il nome diventa un semplice hint per un dispatcher, la corrispondenza tra descrizione contrattuale e runtime è compromessa.

Possibili impatti

Dal punto di vista contrattuale, la distinzione tra aver comprato un "nome" di modello oppure una "capacità" diventa cruciale: una sostituzione può costituire inadempimento se il nome era parte della negoziazione, mentre una fornitura basata su requisito di capacità richiede una definizione misurabile di qualità.

Sul piano probatorio, le regole di autenticazione dei documenti elettronici citate nelle fonti (Federal Rules of Evidence 901/902 e il corrispondente indiano) presuppongono che si possa nominare il sistema che ha prodotto un record. Router non tracciabile o endpoint che forniscono pesi quantizzati senza metadati di runtime interrompono la catena di custodia e complicano sia l'autenticazione sia la discovery in procedimenti giudiziari.

Infine, la disclosure pratica varia molto: alcune piattaforme notificano e specificano il modello servito nel response object; altre pubblicano regole di routing senza assegnare modello per singola richiesta; altre ancora espongono opzioni di quantizzazione che per default privilegiano la strada a basso costo. Disclosure sepolte nella documentazione o impostate come opt-out possono configurare dark pattern regolatori.

Una possibile lettura

I nodi tecnici si stanno già traducendo in questioni legali e di compliance: la soluzione non è solo contrattuale ma tecnica. Le fonti prospettano un rimedio basato su attestazioni firmate a runtime — una "signed assertion" restituita con ogni risposta che leghi la completion a un tuple contenente identificatore del modello servito, hash dei pesi, precisione e hash del system-prompt, firmata con una chiave radicata in attestazione hardware. Questo approccio renderebbe verificabile in modo indipendente quale entità e quale configurazione ha generato un output, trasformando una voce nel response object in un certificato opponibile in contesti probatori.

Se implementata, un'architettura basata su attestazioni potrebbe anche semplificare obblighi di retention dei metadati di routing per discovery, riducendo incertezza per acquirenti, fornitori e organi regolatori. Resta però aperta la definizione contrattuale di "conformità" e la governance su chi produce e verifica le attestazioni: un router che è anche fornitore primario rischia di generare conflitti di interesse che le regole di non-discriminazione e parità di servizio dovranno affrontare.

Fonte: MarkTechPost