Plataforma
Situra se sitúa entre tus aplicaciones y los proveedores de modelos. Habla los dialectos de OpenAI y de Anthropic, elige una ruta permitida para cada petición y registra lo que pasó, sin guardar lo que se dijo.
Una petición ilustrativa de un proyecto con residencia ES: borde de Azure en España, comprobaciones de la pasarela, elección de ruta y medición. Se puede avanzar paso a paso.
1Solo cambia la URL base y la clave. El resto del código sigue igual.
from openai import OpenAI
client = OpenAI(
base_url="https://api.situra.ai/v1",
api_key="situ_live_…",
)
r = client.chat.completions.create(model="gpt-5-mini", …)Los SDK oficiales de OpenAI y Anthropic, los frameworks que se apoyan en ellos y los agentes de código funcionan apuntando la URL base a Situra. Los errores llegan en el dialecto de quien llama.
| Método | Ruta | Compatible con |
|---|---|---|
| POST | /v1/chat/completions | OpenAI Chat Completions, con streaming, herramientas e imágenes |
| POST | /v1/embeddings | OpenAI Embeddings |
| GET | /v1/models | OpenAI List models — solo los modelos que el proyecto de la clave puede usar |
| POST | /v1/messages | Anthropic Messages, con streaming, herramientas e imágenes |
| POST | /v1/messages/count_tokens | Recuento de tokens de Anthropic (estimado si el proveedor no lo ofrece) |
Autenticación con Authorization: Bearer situ_… o, al estilo Anthropic, x-api-key: situ_….
Cualquier modelo del catálogo se puede llamar con cualquiera de los dos formatos: la pasarela traduce peticiones y respuestas, incluido el streaming.
El plano de datos no consulta la base de datos en el camino crítico: trabaja con una instantánea de claves, saldos, límites y rutas que el plano de control le envía por NATS.
Nunca se amplía el nivel
Una alternativa solo puede ser otra ruta del mismo nivel o de uno más estricto. Si no queda ninguna, la respuesta es un 503 (sin ruta permitida) o un 502/504 (fallo del proveedor tras agotar las alternativas).
Cada respuesta servida indica el nivel y la región de la ruta que la sirvió (x-situra-residency, x-situra-route-region); todas indican x-situra-attempts. La cabecera opcional x-situra-residency: es|eu solo puede endurecer el nivel del proyecto.
Se valida el formato y la suma de control, se busca en la instantánea y se verifica el HMAC con la versión de pimienta de la clave.
La clave no ha caducado y la organización está activa (o pendiente de verificación, solo con claves de pruebas).
Peticiones por minuto de la clave; peticiones y tokens por minuto de la organización.
El modelo está en la intersección de la lista de la clave y la del proyecto.
Saldo positivo (prepago) o dentro del límite de crédito (factura), y ningún presupuesto con corte duro agotado.
Rutas activas que el nivel del proyecto permite, con retención cero si el proyecto lo exige, por prioridad y peso.
Si la ruta falla de forma reintentable (429, 5xx, timeout, conexión) antes de enviar el primer byte, se prueba la siguiente ruta permitida.
Tokens reportados por el proveedor, coste al precio vigente de la ruta, latencia y ruta usada.
Por defecto registramos metadatos: quién, qué modelo, cuántos tokens, cuánto costó, cuánto tardó y cómo terminó. El registro de prompts y respuestas se activa por proyecto, con retención de 0 a 365 días y cifrado con la clave de datos de tu organización.
request_idmodelo y rutaproyecto y claveresidencia y regióntokens de entrada y salidatokens de cachécoste en EURlatencia y TTFTintentosestado y tipo de errorDesgloses por modelo, proyecto, clave, proveedor, región y residencia; percentiles de latencia; exportación CSV; comparación con el periodo anterior.
La clave tiene la forma situ_live_<id>_<secreto>, con al menos 256 bits de entropía en el secreto. Guardamos solo un HMAC-SHA256 con una pimienta custodiada en Azure Key Vault.
situ_test_ contra un sandbox determinista, sin coste.
Hay buenas pasarelas y espacios de trabajo de IA. Situra se centra en la residencia por petición, el ENS y el sector público español.
| Solución | Qué ofrece (descripción pública) | En qué se diferencia Situra |
|---|---|---|
| Situra este servicio | Pasarela de IA gestionada en Azure Spain Central (Madrid), compatible con los clientes de OpenAI y Anthropic; residencia ES ⊂ UE ⊂ Global aplicada por proyecto en cada petición. | Aún no certificado: diseñado para ENS categoría Alta; auditoría ENS Media + ISO 27001 prevista para Q2–Q3 2027. Beta privada en Q4 2026. |
| nexos.ai | Pasarela, chat y agentes, observador de adopción; alojado en la UE. | ENS como objetivo de certificación, alojamiento en España, venta y soporte en español. |
| OpenRouter | Agregador amplio de modelos con una única API. | Residencia de datos por proyecto, hoja de ruta de certificación y gobierno empresarial (presupuestos, auditoría, doble aprobación). |
| Open WebUI | Interfaz de código abierto con una capa de pasarela, que opera cada organización. | Servicio gestionado y multiinquilino, con certificación como objetivo. |
| Cohere North | Espacio de trabajo y agentes para empresas. | Pasarela neutral respecto al modelo, ENS como objetivo, foco en el sector público español. |
nexos.ai indica públicamente GDPR, SOC 2 Type II, ISO 27001 e ISO 42001; en nuestra revisión de septiembre de 2026 no figura el ENS. (fuente: nexos.ai)
Basado en las webs públicas de cada proveedor, revisadas en septiembre de 2026. Si algo ha cambiado o es incorrecto, escríbenos y lo corregimos.
El plano de datos es un servicio en Go que integra los adaptadores de proveedor de Bifrost (Apache 2.0) en una versión fijada; la autenticación, la residencia, los presupuestos y la medición son código propio.
Beta privada · Q4 2026
Administraciones públicas españolas y organizaciones reguladas que quieran usar modelos de IA con la residencia de datos bajo control. El acompañamiento incluye la categorización ENS, el DPA y la integración.