Comprar una API de embeddings para una empresa no es como comprar un modelo conversacional. Un modelo de chat se puede cambiar en cualquier momento; los embeddings suelen exigir vectorizar toda la base de una vez y después generan costos de consulta de forma continua, y una vez fijados el modelo y la dimensión, el cambio es costoso.

Por eso la orden de compra no debe limitarse a "cuánta cuota mensual y qué precio unitario", sino cubrir estimación de consumo, facturación y factura, tratamiento de datos, bloqueo de modelo, permisos, degradación y aceptación. La lista siguiente se puede usar directamente para revisar cada punto con el proveedor.

Nota: OpenAI y otros nombres son marcas de sus titulares; este artículo solo ofrece orientación técnica de compra. Las condiciones del producto, los precios y los modelos disponibles pueden cambiar; prevalecen el contrato firmado y las páginas oficiales.

1. Panorama de la lista de compra

Módulo Pregunta clave Material que debe entregarse
Consumo y cuota Cuántos tokens tiene la base, cuántas consultas se hacen, qué límites de velocidad existen Tabla de estimación de capacidad, registro de pruebas de carga
Facturación y factura Unidad de facturación, entidad contratante, tipo de factura Cotización, contrato, factura
Tratamiento de datos Retención, entrenamiento, eliminación DPA, términos, informe de seguridad
Modelo y dimensión Dimensión, idioma, versión y política de descontinuación Lista de modelos, informe de evaluación
Permisos y claves Aislamiento por proyecto, rotación, auditoría Registro de claves, matriz de permisos
Degradación y aceptación Modelo de respaldo, reversión, indicadores de aceptación Registro de simulacros, acta de aceptación

Si algún bloque queda solo en una confirmación verbal, más adelante habrá que rehacer trabajo; el tratamiento de datos y la facturación suelen requerir procesos internos previos.

2. Consumo y cuota: estimar por tokens, no por número de documentos

El consumo de embeddings tiene dos partes: la vectorización de documentos es un costo único de gran volumen y las consultas de usuarios son un costo continuo de poco tráfico. Hay que estimarlas por separado antes de comprar y no dejarse guiar por descripciones como "solo tenemos unos miles de documentos".

Hay cuatro puntos que conviene tener en cuenta:

  1. Muestrear documentos reales y contar tokens con la tokenización o una interfaz de prueba, sin convertir simplemente desde el número de caracteres.
  2. Confirmar si el límite de velocidad se expresa en solicitudes por minuto, tokens por minuto o ambos.
  3. Las tareas de gran volumen deben admitir división en lotes, reintentos y reanudación desde un punto de control, para no empezar de cero tras un límite.
  4. A mayor dimensión, más memoria y disco ocupa la base vectorial; esa parte debe incluirse en el costo total.

La estimación de capacidad se puede resumir en una tabla sencilla:

Costo único ≈ tokens de todos los documentos × tarifa de vectorización
Costo continuo ≈ tokens de consulta mensuales × tarifa de consulta + almacenamiento vectorial y ancho de banda
Margen previsto ≈ 20 %–30 % para reconstrucción de índice, reintentos y crecimiento del negocio

Las tarifas concretas se rigen por los precios de los modelos y la cotización contractual; los precios cambian, así que no conviene fijar en el presupuesto anual una cifra de un momento determinado.

3. Facturación, contrato y factura

En una compra empresarial hay que alinear primero el criterio de facturación. Como mínimo: si se cobra por tokens de entrada o por solicitud; si las llamadas por lotes tienen precios escalonados o compromiso de consumo; si el saldo no utilizado es reembolsable; y si, ante impago o exceso de límite, el servicio se suspende o se degrada.

En contrato y factura hay que confirmar la entidad, la moneda, la forma de pago, el tipo de factura y el ciclo de emisión. A través de una pasarela de IA nacional suele ser posible pagar en moneda local mediante transferencia empresarial y obtener factura; la conexión directa con proveedores extranjeros implica pago transfronterizo, tipo de cambio y otros formatos documentales. Cada vía tiene costos propios; conviene recorrer el proceso financiero antes de elegir.

4. Tratamiento de datos y privacidad: seis documentos que hay que archivar

La entrada de un embedding es texto original, que puede contener datos de clientes, cláusulas contractuales y documentos internos. Al comprar no basta con oír "somos muy seguros": hay que obtener materiales archivables:

  1. Acuerdo de tratamiento de datos (DPA) que defina responsabilidades y alcance.
  2. Descripción de retención y eliminación, con plazos de respuesta a solicitudes de borrado.
  3. Cláusulas explícitas sobre uso para entrenamiento, revisando por separado versión gratuita y de pago.
  4. Lista de subencargados y si se notifican los cambios con antelación.
  5. Respuestas a cuestionarios de seguridad o informes de auditoría independientes.
  6. Indicaciones sobre residencia de datos, transferencia transfronteriza y selección de región.

El vector también puede revelar información semántica. Hay que incluir en la lista de verificación si los vectores se eliminan cuando se borra el texto original, quién puede consultar la base vectorial y cuánto tiempo se conservan las copias de seguridad.

5. Dimensión y bloqueo del modelo

Una dimensión mayor no es necesariamente mejor. Puede aumentar la capacidad de discriminación, pero también el almacenamiento, la latencia de recuperación y el costo; una dimensión menor ahorra recursos, aunque puede perder matices semánticos. Algunos modelos permiten dimensiones personalizadas o reducción; las capacidades concretas dependen de la documentación del modelo.

Más problemático que la dimensión es el bloqueo del modelo. Los espacios vectoriales de modelos distintos no son compatibles, y cambiar de modelo suele implicar reconstruir todo el índice. Al comprar hay que confirmar: si la versión del modelo se actualiza en silencio; cuándo se descontinúa la versión anterior; con cuánta antelación se avisa; y si existe un identificador de versión estable. Es recomendable que el contrato especifique la política de versiones y el plazo de notificación.

6. Control de acceso y gestión de claves

  1. Registrarse con un correo del dominio corporativo y la entidad de la empresa, no con una cuenta personal para operaciones de la compañía.
  2. Usar claves distintas en producción, pruebas y desarrollo, con cuentas separadas por proyecto.
  3. Guardar las claves solo en variables de entorno del servidor o en un gestor de secretos; nunca en el frontend ni en el repositorio de código.
  4. Aplicar el principio de mínimo privilegio y habilitar solo los modelos e interfaces que el negocio necesita.
  5. Establecer procesos de rotación y revocación que se ejecuten de inmediato cuando alguien deja la empresa o se cierra un proyecto.
  6. Activar la auditoría de registros de llamadas; el texto original debe anonimizarse o conservarse solo como metadatos.

Si se usa una pasarela unificada, también hay que confirmar la custodia de claves, la retención de registros, las subcuentas y los límites de consumo; cada capa adicional de servicio añade una frontera más.

7. Degradación y planes de respaldo

Cuando falla un servicio de embeddings, el negocio puede manifestarse como búsquedas sin resultados o una caída brusca de la calidad de RAG, no necesariamente como un error. Por eso hay que diseñar la degradación con antelación:

  • Elegir modelos principal y de respaldo con interfaces compatibles siempre que sea posible, para reducir cambios de código.
  • Si el modelo de respaldo tiene otra dimensión, mantener dos índices o completar de antemano el plan de reconstrucción.
  • Aplicar retroceso y reintento ante límites de velocidad y tiempos de espera; las tareas por lotes deben entrar en cola en lugar de fallar directamente.
  • Practicar la conmutación periódicamente y confirmar que la latencia y la calidad del canal de respaldo son aceptables.

8. Aceptación del piloto: decidir con datos

La aceptación no debe basarse solo en una demostración. Conviene elegir un escenario real de negocio y ejecutar un piloto de alcance reducido con estos pasos:

  1. Extraer entre el 5 % y el 10 % de los documentos de la base, cubriendo formatos, idiomas y tipos de negocio principales.
  2. Preparar al menos 50 consultas reales y anotar a mano los resultados relevantes como referencia.
  3. Ejecutar el modelo principal y el de respaldo, registrando tasa de acierto, latencia, tasa de fallos y activaciones del límite de velocidad.
  4. Contrastar la factura de la plataforma con las estadísticas internas y confirmar que el criterio de facturación coincide.
  5. Verificar que el aislamiento de permisos, las alertas de consumo, el proceso de eliminación y la anonimización de registros funcionan según lo previsto.
  6. Emitir un informe de aceptación con criterios de aprobación y problemas pendientes.

Antes del lanzamiento conviene validar con una solicitud mínima la clave, el nombre del modelo y la dimensión devuelta:

curl "https://ai.zhongshangqihang.com/v1/embeddings" \
  -H "Authorization: Bearer $EMBEDDING_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"text-embedding-3-small","input":["texto de prueba de aceptación empresarial"]}'

La dimensión del vector devuelto debe coincidir con la estructura de la tabla de la base vectorial; si no coincide, primero se corrige la configuración y no se escribe directamente en la base de producción. El nombre de modelo del ejemplo solo sirve para la demostración; los modelos disponibles se rigen por la documentación del sitio.

9. Monitoreo de costos y revisión mensual

El costo de los embeddings se caracteriza por una inversión inicial única y un gasto continuo y disperso; lo que más se pasa por alto es la reconstrucción de índices y las consultas repetidas. Se recomienda revisar cada mes cuatro cosas: consumo de tokens por proyecto, número de vectorizaciones de consulta, número de reconstrucciones de índice y desviación de la factura.

Entre las medidas de optimización están el almacenamiento en caché de vectores de consultas frecuentes, la fusión de solicitudes por lotes y el filtrado de llamadas sin sentido. Cualquier optimización debe confirmar antes que no afecta la calidad de la recuperación.

10. Preguntas frecuentes

¿Cómo se suele facturar una API de embeddings?

La mayoría de las plataformas cobra por tokens de entrada; algunas ofrecen tramos distintos para tareas por lotes o consumo comprometido. La unidad y la tarifa concretas dependen de la página oficial o del contrato, y al comprar hay que estimar por separado las consultas y la vectorización de documentos.

¿Los vectores se consideran datos sensibles?

Deben tratarse como tales. Un vector puede usarse para inferir la semántica original, así que los permisos de acceso a la base vectorial, el cifrado y las copias de seguridad deben gestionarse con el mismo nivel que el texto original.

¿Hay que reconstruir el índice al cambiar de modelo de embeddings?

Normalmente sí. Los espacios vectoriales de modelos distintos no son compatibles y, aunque la dimensión coincida, no se garantiza que se puedan mezclar. Antes de cambiar hay que reservar tiempo y presupuesto para la reconstrucción y preparar un plan de reversión.

¿Una empresa necesita un contrato aparte para usar embeddings?

Siempre que haya datos corporativos, reembolso empresarial o servicios externos, conviene formalizar contrato y pago corporativo. Las condiciones en línea pueden servir de complemento, pero la responsabilidad del tratamiento de datos, el nivel de servicio y los requisitos de factura deben quedar por escrito en el contrato.

¿Se puede usar la cuota gratuita en un piloto empresarial?

Sirve para validar la interfaz y los resultados con muestras anonimizadas, pero no conviene enviar datos de producción o documentos sensibles a un nivel gratuito público. Una vez aprobado el piloto, el tráfico de producción debe pasar a un servicio de pago con condiciones claras de tratamiento de datos.

Siguiente paso

Si se necesita gestionar de forma unificada las llamadas de embeddings de varios modelos y separar claves y presupuestos por proyecto, se puede registrar en ZSQH AI Gateway, ejecutar con un lote pequeño de documentos los puntos clave de la lista de aceptación y después decidir la escala de compra. Los modelos disponibles y los precios figuran en los precios de los modelos.

Lecturas relacionadas: