DeepSeek: cómo decidir entre API oficial, pesos publicados y proveedores externos sin confundir apertura con control operativo

La unidad de decisión no es el nombre DeepSeek

Adoptar DeepSeek no equivale a seleccionar de una vez una familia, una variante y un canal de ejecución. Una organización puede usar un endpoint operado por DeepSeek, descargar y ejecutar pesos publicados, o contratar a un tercero que exponga un modelo con ese nombre. Estas opciones pueden compartir parte de una genealogía técnica, pero asignan de forma distinta el control, el riesgo y la responsabilidad operativa.

La primera disciplina consiste en evitar que un nombre comercial sustituya al inventario técnico. «DeepSeek-R1», «DeepSeek-V3» o una denominación posterior pueden aparecer en anuncios, repositorios, interfaces de chat y catálogos de API. Ninguna de esas apariciones demuestra por sí misma qué revisión recibe una petición, qué pesos la producen, qué configuración de inferencia se aplica o quién procesa los datos. Antes de comparar capacidades, el equipo debe identificar el objeto exacto que pretende aprobar.

Esto importa especialmente cuando un alias de API conserva un nombre estable. El registro de cambios de la API de DeepSeek documenta lanzamientos, retiradas, redirecciones de alias y periodos de compatibilidad. Por tanto, un identificador invocable puede no ser una garantía de inmovilidad del modelo subyacente. No es un defecto en sí mismo: puede facilitar actualizaciones gestionadas. Pero obliga a decidir si el producto necesita una capacidad actualizada por el operador o una versión fijada y reproducible.

La pregunta operativa correcta es: «¿qué modelo o servicio, operado por quién, bajo qué condiciones y con qué evidencia, se usará para esta función concreta?». El directorio de organizaciones puede servir para localizar el perfil de DeepSeek y el comparador para situar alternativas, pero la decisión debe conservar pruebas propias por cada canal de acceso.

Inventario de superficies de acceso y pruebas que las identifican

La API oficial es un servicio remoto. El equipo consume una interfaz, un identificador de modelo y unas condiciones de plataforma, mientras la infraestructura de inferencia queda bajo control del operador. Sus ventajas potenciales son reducir la operación propia y permitir cambios administrados; sus contrapartidas son la dependencia de la disponibilidad, los límites, la evolución del servicio y la información que se envía al endpoint.

Los pesos publicados son un artefacto que una organización puede obtener y ejecutar en infraestructura bajo su control, siempre que cumpla la licencia correspondiente. Ese control puede ayudar a fijar una revisión, restringir la red, elegir región y definir la retención de logs. Sin embargo, no incluye automáticamente un servicio de producción: hay que construir o contratar inferencia, autenticación, observabilidad, escalado, evaluación, respuesta ante incidentes y gestión de vulnerabilidades.

Un proveedor externo añade otra capa. Puede ofrecer una región determinada, facturación integrada, controles de red, métricas o soporte comercial. También puede servir una variante adaptada, cuantizada, encaminada mediante un alias o sustituida con el tiempo. Su afirmación de compatibilidad con una API o de disponibilidad de un modelo DeepSeek no prueba identidad con el servicio oficial ni con un checkpoint publicado.

El inventario inicial debe registrar para cada caso el canal, el operador, el nombre mostrado al usuario, el identificador enviado en la solicitud, la fecha de observación, el entorno, la versión del cliente y la fuente documental. Cuando se trate de pesos, debe añadir repositorio, revisión o hash verificable, formato, método de conversión y configuración de inferencia. Sin este registro, una incidencia posterior no podrá atribuirse con rigor a un cambio de modelo, de infraestructura o de aplicación.

Licencias: pesos, código y servicio son capas separadas

La licencia del código no debe utilizarse como resumen de los derechos sobre los pesos. En el repositorio de DeepSeek-V3, el archivo de licencia de código está bajo MIT, mientras que el archivo de licencia del modelo contiene condiciones específicas para el modelo. La diferencia documental es decisiva: una autorización amplia sobre código no elimina las obligaciones, avisos, restricciones o condiciones que puedan afectar al artefacto de modelo.

La licencia del modelo V3 contempla condiciones relativas al uso, el alojamiento o la redistribución, la conservación de avisos y los derivados. Un responsable de compras o de cumplimiento no debería convertir esta descripción en una conclusión jurídica simplificada. Debe leer la versión aplicable al artefacto que descargará, conservarla con el expediente y confirmar si su forma de distribución, su aplicación final y sus modificaciones activan obligaciones concretas.

Tampoco debe confundirse una licencia con soporte. Una licencia puede autorizar determinados usos de un checkpoint sin prometer disponibilidad de un endpoint, correcciones de seguridad, nivel de servicio, compatibilidad de herramientas, respuesta a incidencias o continuidad de una variante. Del mismo modo, un contrato de API regula una relación de plataforma y no convierte automáticamente a sus usuarios en distribuidores de pesos.

Las condiciones de servicio de la plataforma abierta describen el marco de uso de la plataforma de desarrolladores y asignan al desarrollador responsabilidades respecto de sus aplicaciones y usuarios posteriores. Esto exige una revisión conjunta entre ingeniería, seguridad, privacidad, compras y asesoría jurídica. El artículo no sustituye esa revisión: la aplicabilidad concreta depende del artefacto, del país, de la arquitectura y de la relación contractual.

API oficial: controlar el contrato de integración, no solo la llamada

En una integración mediante API oficial, el modelo es solo una parte de la dependencia. Deben verificarse la autenticación, cuotas, límites de velocidad, ventanas de contexto, formatos de respuesta, compatibilidad de herramientas, manejo de errores y comportamiento ante reintentos. La prueba debe realizarse con el identificador que irá a producción y con una carga representativa, no únicamente con una conversación manual exitosa.

El registro de cambios es una fuente operativa esencial porque publica cambios de lanzamiento, retirada y compatibilidad. Conviene incorporar su revisión al proceso de gestión de cambios. Si la aplicación depende de un alias, el expediente debe indicar que existe riesgo de modificación del modelo efectivo. Si requiere reproducibilidad, debe preguntarse al operador qué mecanismo documentado permite fijar una versión o, si no existe, limitar la promesa del producto y conservar resultados de pruebas por fecha.

Las condiciones de la plataforma abierta son relevantes para delimitar responsabilidades del desarrollador. La política de privacidad de DeepSeek declara categorías de datos tratadas, incluidas entradas de usuarios y datos vinculados a pagos de la plataforma abierta, además de describir almacenamiento y procesamiento. Esa documentación es útil para abrir una evaluación, pero no basta para inferir aislamiento exclusivo, residencia concreta, plazos de retención aplicables a cada tipo de cuenta, uso para entrenamiento o garantías contractuales no expresadas en los documentos disponibles.

Por ello, un equipo que vaya a enviar información interna, datos de clientes o datos regulados debe separar lo publicado de lo garantizado. Debe obtener, por el canal comercial o jurídico pertinente, respuestas escritas sobre tratamiento, ubicaciones, retención, subencargados, notificación de incidentes, borrado, controles de acceso y anexos aplicables. Hasta entonces, la clasificación de datos y el diseño de minimización deben asumir incertidumbre.

Pesos propios: mayor control técnico, mayor perímetro de responsabilidad

Operar pesos propios puede aportar una forma más directa de congelar una revisión y decidir dónde se ejecuta. Sin embargo, esa afirmación solo es válida si se conserva el artefacto exacto, se verifican sus identificadores y se controla toda la cadena de despliegue. Descargar un repositorio por nombre, usar una etiqueta móvil o aceptar una imagen de contenedor sin registrar su procedencia no equivale a reproducibilidad.

El equipo hereda tareas que en una API gestiona el operador: selección y mantenimiento del motor de inferencia, compatibilidad de hardware, cuantización, paralelismo, límites de concurrencia, protección de secretos, filtrado de entradas, registro de eventos, copias de seguridad, actualización de dependencias, observabilidad y respuesta ante incidentes. También debe evaluar cambios causados por plantillas de conversación, parámetros de decodificación, herramientas conectadas y capas de seguridad propias. Dos instalaciones basadas en los mismos pesos pueden responder de forma diferente.

La apertura de un artefacto tampoco demuestra por sí sola su seguridad para un caso de uso. En las fuentes disponibles para este análisis no se aporta una garantía contractual de seguridad, ni una system card que permita derivar una evaluación completa por familia. La ausencia de tal evidencia pública no prueba que el modelo sea inseguro; significa que no debe afirmarse que cumple un nivel determinado sin pruebas independientes y criterios definidos por el adoptante.

La evaluación debe incluir el flujo real de la aplicación. Es insuficiente medir una tarea de referencia o una tasa global de aciertos. Hacen falta pruebas de fuga de instrucciones, contenido no deseado, extracción de datos, abuso de herramientas, degradación bajo carga, recuperación ante reinicio y regresiones entre revisiones. Las decisiones de producción deben depender de umbrales documentados y de un responsable que acepte el riesgo residual.

Proveedores externos: evaluar la capa añadida sin asumir identidad

Un proveedor externo puede ser razonable cuando aporta una condición que el equipo necesita, como facturación centralizada, una zona de despliegue, conectividad privada, observabilidad o soporte. Estas capacidades deben validarse como propiedades de ese proveedor, no como propiedades inherentes de DeepSeek. Del mismo modo, una garantía que ofrezca el tercero no se traslada automáticamente a la API oficial, a los pesos publicados ni a otro revendedor.

La diligencia mínima comienza por identificar al operador que recibe la solicitud y al que factura el servicio. Después debe pedir la variante declarada, el mecanismo de versionado, las reglas de sustitución, la infraestructura o región aplicable, la política de logs, el tratamiento de datos, los subproveedores, el soporte y el proceso de notificación de cambios. Si la respuesta se limita a una etiqueta comercial, debe clasificarse la versión como no verificada.

La compatibilidad de protocolos solo describe una interfaz. Un endpoint compatible puede aceptar una estructura de petición similar y, aun así, aplicar una versión diferente, una cuantización distinta, una plantilla propia, límites distintos o encaminamiento a más de un backend. Tampoco puede inferirse, sin una prueba y una declaración del operador, que sirve el mismo checkpoint y la misma configuración que otro endpoint.

En la contratación, las pruebas deben combinar revisión documental y medición. Ejecute casos de regresión, evalúe límites y tiempos de respuesta, compruebe la exportación de logs permitida y simule una retirada o un cambio de modelo. Si la aplicación usa funciones, herramientas o salida estructurada, pruébelas con entradas adversas y con fallos parciales. El objetivo no es demostrar una equivalencia abstracta, sino comprobar que el servicio contratado satisface los requisitos declarados.

Clasificación de uso y registro de cambios

La aprobación no debe ser binaria. Un canal puede ser suficiente para exploración y no para producción. Para un experimento, puede bastar una cuenta controlada, datos sintéticos, una prueba funcional y una anotación de incertidumbres. Para uso interno acotado, se añaden clasificación de datos, controles de acceso, evaluación de riesgos y seguimiento de cambios. Para producción orientada a clientes, la exigencia aumenta: arquitectura de continuidad, propietario operativo, evidencia contractual cuando corresponda, pruebas de seguridad y un mecanismo de reversión.

El registro de cambios debe ser un artefacto vivo, no una nota en una presentación. Por cada despliegue, conserve el canal de acceso, operador, identificador invocado, familia y variante declaradas, revisión o hash cuando exista, fecha, configuración relevante, versión del cliente, región conocida, límites observados, batería de evaluación y resultados. Añada una decisión explícita sobre las incertidumbres aceptadas.

Esta disciplina permite responder a preguntas posteriores con precisión: si una salida cambió, si se modificó el endpoint, si la aplicación cambió su plantilla, si se actualizó un peso o si falló una dependencia. También evita que la organización atribuya a DeepSeek una propiedad que pertenece al proveedor externo o a su propio entorno. La apertura puede ampliar opciones de despliegue, pero no reemplaza la gestión de configuración, la evaluación ni la responsabilidad de quien entrega el producto final.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.