DeepSeek: come decidere tra API ufficiale, pesi pubblicati e fornitori esterni senza confondere apertura e controllo operativo

L'unità decisionale non è il nome DeepSeek

Adottare DeepSeek non equivale a scegliere una volta per tutte una famiglia, una variante e un canale di esecuzione. Un'organizzazione può usare un endpoint gestito da DeepSeek, scaricare ed eseguire pesi pubblicati oppure contrattualizzare un soggetto terzo che espone un modello con questo nome. Queste opzioni possono condividere una parte della genealogia tecnica, ma distribuiscono in modo diverso controllo, rischio e responsabilità operativa.

La prima disciplina consiste nell'evitare che un nome commerciale sostituisca l'inventario tecnico. «DeepSeek-R1», «DeepSeek-V3» o una denominazione successiva possono comparire in annunci, repository, interfacce chat e cataloghi API. Nessuna di queste presenze dimostra di per sé quale revisione riceva una richiesta, quali pesi la producano, quale configurazione di inferenza venga applicata o chi tratti i dati. Prima di confrontare le capacità, il team deve identificare l'oggetto esatto che intende approvare.

Questo è particolarmente importante quando un alias API mantiene un nome stabile. Il changelog dell'API DeepSeek documenta rilasci, ritiri, reindirizzamenti di alias e periodi di compatibilità. Di conseguenza, un identificatore invocabile può non costituire una garanzia di immutabilità del modello sottostante. Non è un difetto in sé: può agevolare aggiornamenti gestiti. Ma impone di decidere se il prodotto richieda una capacità aggiornata dall'operatore oppure una versione fissata e riproducibile.

La domanda operativa corretta è: «quale modello o servizio, gestito da chi, a quali condizioni e con quali evidenze, verrà usato per questa funzione specifica?». La directory delle organizzazioni può servire per individuare il profilo di DeepSeek e il comparatore per collocare le alternative, ma la decisione deve conservare prove proprie per ciascun canale di accesso.

Inventario delle superfici di accesso e delle prove che le identificano

L'API ufficiale è un servizio remoto. Il team utilizza un'interfaccia, un identificatore di modello e condizioni di piattaforma, mentre l'infrastruttura di inferenza resta sotto il controllo dell'operatore. I suoi potenziali vantaggi sono la riduzione dell'operatività interna e la possibilità di modifiche gestite; i corrispettivi sono la dipendenza dalla disponibilità, dai limiti, dall'evoluzione del servizio e dalle informazioni inviate all'endpoint.

I pesi pubblicati sono un artefatto che un'organizzazione può ottenere ed eseguire su infrastruttura sotto il proprio controllo, a condizione di rispettare la licenza pertinente. Questo controllo può aiutare a fissare una revisione, limitare la rete, scegliere una regione e definire la conservazione dei log. Tuttavia non include automaticamente un servizio di produzione: occorre costruire o acquisire inferenza, autenticazione, osservabilità, scalabilità, valutazione, risposta agli incidenti e gestione delle vulnerabilità.

Un fornitore esterno aggiunge un ulteriore livello. Può offrire una determinata regione, fatturazione integrata, controlli di rete, metriche o supporto commerciale. Può anche erogare una variante adattata, quantizzata, instradata tramite un alias o sostituita nel tempo. La sua dichiarazione di compatibilità con un'API o di disponibilità di un modello DeepSeek non prova l'identità né con il servizio ufficiale né con un checkpoint pubblicato.

L'inventario iniziale deve registrare per ogni caso il canale, l'operatore, il nome mostrato all'utente, l'identificatore inviato nella richiesta, la data di osservazione, l'ambiente, la versione del client e la fonte documentale. Per i pesi deve aggiungere repository, revisione o hash verificabile, formato, metodo di conversione e configurazione di inferenza. Senza questo registro, un incidente successivo non potrà essere attribuito con rigore a un cambiamento del modello, dell'infrastruttura o dell'applicazione.

Licenze: pesi, codice e servizio sono livelli distinti

La licenza del codice non deve essere usata come riassunto dei diritti sui pesi. Nel repository DeepSeek-V3, il file della licenza del codice è rilasciato sotto MIT, mentre il file della licenza del modello contiene condizioni specifiche per il modello. La differenza documentale è decisiva: un'autorizzazione ampia sul codice non elimina gli obblighi, gli avvisi, le restrizioni o le condizioni che possono riguardare l'artefatto del modello.

La licenza del modello V3 contempla condizioni relative all'uso, all'hosting o alla ridistribuzione, alla conservazione degli avvisi e ai derivati. Un responsabile acquisti o conformità non dovrebbe trasformare questa descrizione in una conclusione giuridica semplificata. Deve leggere la versione applicabile all'artefatto che scaricherà, conservarla nel fascicolo e confermare se la propria modalità di distribuzione, l'applicazione finale e le modifiche attivino obblighi specifici.

Non si deve nemmeno confondere una licenza con il supporto. Una licenza può autorizzare determinati usi di un checkpoint senza promettere disponibilità di un endpoint, correzioni di sicurezza, livello di servizio, compatibilità degli strumenti, risposta agli incidenti o continuità di una variante. Allo stesso modo, un contratto API disciplina una relazione di piattaforma e non trasforma automaticamente i suoi utenti in distributori di pesi.

I termini di servizio della piattaforma aperta descrivono il quadro d'uso della piattaforma per sviluppatori e assegnano allo sviluppatore responsabilità relative alle proprie applicazioni e agli utenti successivi. Ciò richiede una revisione congiunta fra ingegneria, sicurezza, privacy, acquisti e consulenza legale. Questo articolo non sostituisce tale revisione: l'applicabilità concreta dipende dall'artefatto, dal Paese, dall'architettura e dalla relazione contrattuale.

API ufficiale: controllare il contratto di integrazione, non solo la chiamata

In un'integrazione tramite API ufficiale, il modello è soltanto una parte della dipendenza. Occorre verificare autenticazione, quote, limiti di frequenza, finestre di contesto, formati di risposta, compatibilità degli strumenti, gestione degli errori e comportamento in caso di ritentativi. Il test deve essere svolto con l'identificatore destinato alla produzione e con un carico rappresentativo, non solo con una conversazione manuale riuscita.

Il changelog è una fonte operativa essenziale perché pubblica modifiche di rilascio, ritiro e compatibilità. Conviene integrare la sua revisione nel processo di gestione delle modifiche. Se l'applicazione dipende da un alias, il fascicolo deve indicare che esiste il rischio di modifica del modello effettivo. Se richiede riproducibilità, deve chiedere all'operatore quale meccanismo documentato permetta di fissare una versione o, se non esiste, limitare la promessa del prodotto e conservare risultati dei test per data.

I termini della piattaforma aperta sono pertinenti per delimitare le responsabilità dello sviluppatore. La politica sulla privacy di DeepSeek dichiara categorie di dati trattati, incluse le immissioni degli utenti e dati collegati ai pagamenti della piattaforma aperta, oltre a descrivere archiviazione e trattamento. Questa documentazione è utile per avviare una valutazione, ma non basta per dedurre isolamento esclusivo, residenza concreta, tempi di conservazione applicabili a ogni tipo di account, uso per addestramento o garanzie contrattuali non espresse nei documenti disponibili.

Di conseguenza, un team che intenda inviare informazioni interne, dati dei clienti o dati regolamentati deve separare ciò che è pubblicato da ciò che è garantito. Deve ottenere, attraverso il canale commerciale o legale appropriato, risposte scritte su trattamento, ubicazioni, conservazione, sub-responsabili, notifica degli incidenti, cancellazione, controlli di accesso e allegati applicabili. Fino ad allora, la classificazione dei dati e la progettazione della minimizzazione devono assumere l'incertezza.

Pesi propri: maggiore controllo tecnico, maggiore perimetro di responsabilità

Gestire pesi propri può offrire una modalità più diretta per congelare una revisione e decidere dove eseguirla. Tuttavia, questa affermazione vale solo se si conserva l'artefatto esatto, se ne verificano gli identificatori e si controlla l'intera catena di rilascio. Scaricare un repository per nome, usare un tag mobile o accettare un'immagine container senza registrarne la provenienza non equivale alla riproducibilità.

Il team eredita attività che in un'API sono gestite dall'operatore: scelta e manutenzione del motore di inferenza, compatibilità hardware, quantizzazione, parallelismo, limiti di concorrenza, protezione dei segreti, filtraggio degli input, registrazione degli eventi, backup, aggiornamento delle dipendenze, osservabilità e risposta agli incidenti. Deve inoltre valutare modifiche causate da template conversazionali, parametri di decodifica, strumenti connessi e livelli di sicurezza propri. Due installazioni basate sugli stessi pesi possono rispondere in modo differente.

L'apertura di un artefatto non dimostra da sola la sua sicurezza per un caso d'uso. Nelle fonti disponibili per questa analisi non viene fornita una garanzia contrattuale di sicurezza né una system card da cui ricavare una valutazione completa per famiglia. L'assenza di tale evidenza pubblica non prova che il modello sia insicuro; significa che non si deve affermare che soddisfi un determinato livello senza test indipendenti e criteri definiti dall'adottante.

La valutazione deve includere il flusso reale dell'applicazione. Non basta misurare un compito di riferimento o un tasso globale di accuratezza. Servono test su fuga di istruzioni, contenuti indesiderati, estrazione di dati, abuso degli strumenti, degrado sotto carico, recupero dopo riavvio e regressioni fra revisioni. Le decisioni di produzione devono dipendere da soglie documentate e da un responsabile che accetti il rischio residuo.

Fornitori esterni: valutare il livello aggiunto senza presumere identità

Un fornitore esterno può essere ragionevole quando offre una condizione necessaria al team, come fatturazione centralizzata, una zona di distribuzione, connettività privata, osservabilità o supporto. Queste capacità devono essere convalidate come proprietà di quel fornitore, non come proprietà intrinseche di DeepSeek. Analogamente, una garanzia offerta dal terzo non si trasferisce automaticamente all'API ufficiale, ai pesi pubblicati o a un altro rivenditore.

La dovuta diligenza minima inizia identificando l'operatore che riceve la richiesta e fattura il servizio. Occorre poi chiedere la variante dichiarata, il meccanismo di versionamento, le regole di sostituzione, l'infrastruttura o la regione applicabile, la politica sui log, il trattamento dei dati, i subfornitori, il supporto e il processo di notifica delle modifiche. Se la risposta si limita a un'etichetta commerciale, la versione deve essere classificata come non verificata.

La compatibilità dei protocolli descrive soltanto un'interfaccia. Un endpoint compatibile può accettare una struttura di richiesta simile e, comunque, applicare una versione diversa, una quantizzazione differente, un template proprietario, limiti diversi o instradamento verso più backend. Non si può nemmeno dedurre, senza un test e una dichiarazione dell'operatore, che serva lo stesso checkpoint e la stessa configurazione di un altro endpoint.

Nella contrattualizzazione, le verifiche devono combinare revisione documentale e misurazione. Eseguire casi di regressione, valutare limiti e tempi di risposta, verificare l'esportazione consentita dei log e simulare un ritiro o un cambio di modello. Se l'applicazione usa funzioni, strumenti o output strutturato, provarli con input avversi e guasti parziali. L'obiettivo non è dimostrare un'equivalenza astratta, ma verificare che il servizio contrattualizzato soddisfi i requisiti dichiarati.

Classificazione d'uso e registro delle modifiche

L'approvazione non deve essere binaria. Un canale può essere sufficiente per l'esplorazione e non per la produzione. Per un esperimento possono bastare un account controllato, dati sintetici, un test funzionale e un'annotazione delle incertezze. Per un uso interno delimitato si aggiungono classificazione dei dati, controlli di accesso, valutazione dei rischi e monitoraggio dei cambiamenti. Per una produzione rivolta ai clienti, il requisito aumenta: architettura di continuità, proprietario operativo, evidenza contrattuale ove pertinente, test di sicurezza e un meccanismo di rollback.

Il registro delle modifiche deve essere un artefatto vivo, non una nota in una presentazione. Per ogni rilascio, conservare il canale di accesso, l'operatore, l'identificatore invocato, la famiglia e la variante dichiarate, revisione o hash quando esistono, data, configurazione rilevante, versione del client, regione nota, limiti osservati, batteria di valutazione e risultati. Aggiungere una decisione esplicita sulle incertezze accettate.

Questa disciplina consente di rispondere con precisione a domande successive: se un output è cambiato, se è stato modificato l'endpoint, se l'applicazione ha cambiato template, se è stato aggiornato un peso oppure se una dipendenza ha avuto un guasto. Evita anche che l'organizzazione attribuisca a DeepSeek una proprietà che appartiene al fornitore esterno o al proprio ambiente. L'apertura può ampliare le opzioni di distribuzione, ma non sostituisce la gestione della configurazione, la valutazione né la responsabilità di chi consegna il prodotto finale.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.