HopBaseRespuesta corta: la revisión de seguridad empresarial de un proveedor de API de LLM se reduce a cuatro capas: la gobernanza de claves (mínimo privilegio y revocación inmediata: una clave filtrada debe comprometerse sola y poder revocarse en segundos sin afectar el tráfico de ningún otro equipo), la ruta de los datos (si el contenido de solicitudes y respuestas se persiste alguna vez, qué campos conservan los registros y durante cuánto tiempo, y si algo de ello puede usarse para entrenamiento), la auditoría y conciliación (cada llamada trazable a una clave, un modelo y un recuento de tokens; las solicitudes fallidas no se facturan y cualquier salida generada parcialmente se etiqueta como tal) y la verificabilidad del proveedor (las promesas verbales no cuentan; solo cuenta el comportamiento que usted puede reproducir). A continuación encontrará una lista de diez puntos en la que cada fila indica no solo el criterio para aprobar, sino también cómo verificarlo usted mismo: cree dos claves y revoque una, provoque un fallo y revise la factura. Úsela con cualquier proveedor, incluidos nosotros.
Capa 1: gobernanza de claves
Casi todos los incidentes empiezan con una credencial filtrada. El único principio sólido: el radio de impacto de cualquier clave individual debe ser mínimo.
- Una clave por aplicación y por equipo: una filtración compromete una sola clave, y revocarla no afecta a nada más;
- Listas de modelos permitidos: una clave solo puede llamar a los modelos que ofrecen los grupos que incluye, de modo que una clave filtrada no puede llegar a nada fuera de ese ámbito;
- Cuotas independientes: por clave, por miembro y por departamento, para que una integración descontrolada no consuma el presupuesto global;
- Almacenamiento solo de hashes: HopBase almacena las API keys como hashes unidireccionales; las claves en texto plano nunca llegan a la base de datos, así que ni siquiera una base de datos robada puede revelar su clave.
Capa 2: la ruta de los datos
Plantee tres preguntas por escrito a cualquier proveedor:
- ¿Se persiste alguna vez el contenido de las solicitudes y respuestas?
- ¿Qué campos conservan los registros y durante cuánto tiempo?
- ¿Pueden los datos usarse alguna vez para entrenamiento o cualquier fin secundario?
Nuestra posición publicada: sin retención de contenido a largo plazo. Los prompts y las salidas solo se usan para completar cada solicitud: no se guardan como datos de negocio ni se usan para entrenar modelos. Los metadatos de facturación (modelo, recuento de tokens, latencia, estado) se conservan para facturas y auditorías; las solicitudes fallidas pueden guardarse brevemente para diagnosticar el error y después se eliminan automáticamente. Todo el tráfico está cifrado con TLS en tránsito. Los atributos de canal de cada plan están indicados en nuestra página de precios, para que pueda evaluarlos plan por plan.
Capa 3: auditoría y conciliación
- Cada solicitud deja un rastro (modelo, uso, latencia, estado), de modo que las anomalías pueden rastrearse hasta una clave, un momento, un modelo y un volumen;
- el detalle de uso es exportable, y los importes facturados equivalen al consumo real;
- las solicitudes fallidas no se facturan: una solicitud que falla antes de producir salida no cuesta nada. La única excepción es una solicitud interrumpida cuando ya se había generado salida (por ejemplo, el cliente se desconecta a mitad del stream): se cobra por el uso ya generado y se etiqueta como "Request interrupted, charged for the usage already generated" en la exportación, para que cada fila pueda comprobarse.
Capa 4: verificabilidad del proveedor
Todos afirman que no cambian de modelo, que no degradan en silencio y que no retienen datos. Las afirmaciones no se pueden verificar; el comportamiento sí. Exija a su proveedor que:
- publique los atributos de canal: sobre qué funciona cada plan, de forma abierta;
- transmita los errores: los códigos de error del proveedor del modelo se devuelven tal cual, nunca se ocultan ni se reescriben;
- acepte las pruebas: un proveedor que se opone a una prueba de fidelidad reproducible ya ha respondido a su pregunta.
La lista de verificación en una página
| Punto | Criterio para aprobar | Cómo verificarlo |
|---|---|---|
| Granularidad de claves | Una clave por aplicación, revocación inmediata | Cree dos claves, revoque una y confirme que la otra no se ve afectada |
| Lista de modelos permitidos | Las claves solo llegan a los modelos autorizados | Llame a un modelo no autorizado; debe obtener un rechazo limpio |
| Aislamiento de cuotas | Independientes por clave/miembro/departamento | Agote la cuota de una clave de prueba; las demás claves no deben verse afectadas |
| Retención de contenido | Sin retención a largo plazo de prompts/salidas ni uso para entrenamiento; alcance y plazo de retención documentados | Exija por escrito la política de retención y la lista de campos |
| Transporte | TLS en todas partes | Inspeccione la cadena de certificados; HTTP en texto plano es descalificante |
| Almacenamiento de claves | El servidor solo guarda hashes | Pregunte: ¿puede una filtración de la base de datos revelar claves en texto plano? |
| Granularidad de auditoría | Modelo/uso/latencia/estado por solicitud | Exporte el detalle de uso y revíselo por muestreo |
| Facturación en caso de fallo | Las solicitudes fallidas no cuestan nada; las interrumpidas tras generar salida se etiquetan | Provoque fallos y revise la factura y las notas de la exportación |
| Transmisión de errores | Los códigos de error del proveedor se devuelven tal cual | Provoque un límite de tasa; compárelo con el comportamiento oficial |
| Fidelidad | El proveedor acepta las pruebas | Ejecute las cinco comprobaciones de fidelidad y observe la reacción |
Preguntas frecuentes
¿HopBase almacena mis datos o los usa para entrenamiento?
No se usan para entrenar modelos ni se guardan como datos de negocio. Los prompts y las salidas solo se usan para completar cada solicitud; los metadatos de facturación (modelo, recuento de tokens, latencia, estado) se conservan para facturas y auditorías, y las solicitudes fallidas pueden guardarse brevemente para diagnosticar el error y después se eliminan automáticamente.
¿Un gateway es un salto adicional y, por tanto, un riesgo adicional?
Ese salto aporta una gobernanza centralizada: niveles de claves, cuotas, listas de permitidos, auditoría y revocación uniformes. La alternativa (N equipos, cada uno con claves directas del proveedor) tiene una superficie de filtración mayor y un costo de gobernanza más alto. La ruta en sí usa TLS de extremo a extremo.
¿Cómo debo usar esta lista de verificación?
Evalúe varios proveedores en paralelo con ella, exigiendo una demostración o una confirmación por escrito para cada punto; verifique el lado del modelo con la prueba de fidelidad. Solo después hable de precios.
Para la incorporación empresarial y la revisión de seguridad, contáctenos; los detalles de integración están en la documentación.