Google Cloud
La plataforma sobre la que corren nuestras propias aplicaciones. Es donde podemos enseñar un sistema en producción, no un diagrama.
Ingeniería · Infraestructura
Infraestructura cloud con residencia de datos en la UE
Nuestra infraestructura de producción es Google Cloud, y la inferencia corre en europe-southwest1 (Madrid). La región no se elige por precio: se elige por dónde tienen que vivir los datos. Cuando el dominio está regulado, eso deja de ser un detalle técnico y pasa a aparecer en el contrato y en la auditoría.
Actualizado:
Definiciones clave
- Residencia de datos
- Compromiso de que los datos y su procesamiento permanecen físicamente en una zona geográfica determinada. En nuestro caso, la Unión Europea.
- Región (cloud)
- Zona geográfica concreta donde el proveedor tiene los centros de datos que ejecutan tu sistema. No es una preferencia: en un dominio regulado es un requisito contractual.
- europe-southwest1
- La región de Google Cloud ubicada en Madrid. Es donde corre la inferencia de IA de nuestras plataformas: Vertex AI sobre Gemini, con los datos dentro de la UE.
- Integración continua (CI)
- Proceso automático que compila y comprueba cada cambio antes de que llegue a producción. Ningún despliegue se salta ese paso.
Dónde corre la infraestructura, y por qué la región es un requisito
La pregunta que más pesa en una infraestructura para trabajo regulado no es qué servicios se usan: es dónde están los datos. La región deja de ser una casilla del formulario de alta y pasa a ser un requisito contractual. Un cliente que maneja expedientes con datos personales no pregunta por la arquitectura: pregunta en qué país se procesa su información, y «está en la nube» no es una respuesta.
Nuestra infraestructura de producción corre sobre Google Cloud. La inferencia de IA se ejecuta en Vertex AI sobre Gemini, en la región europe-southwest1, que es Madrid. Datos y modelo permanecen dentro de la Unión Europea. Eso no es una promesa comercial: es la región en la que está desplegado el proyecto, y se comprueba abriendo la consola.
Sobre AWS y Azure conviene ser claro, porque esta página se llama como se llama. Nuestra experiencia en producción es Google Cloud. AWS y Azure son plataformas equivalentes para la mayoría de los casos, pero hoy no operamos sistemas productivos sobre ellas, y decir lo contrario sería justo el tipo de afirmación que no podríamos demostrar si nos la pidieran. Si tu sistema ya vive en AWS o en Azure, podemos construir contra él e integrarnos con él; moverlo o no es una decisión tuya, no una venta nuestra.
La cuenta cloud es del cliente. La infraestructura se despliega en un proyecto a su nombre, el consumo se le factura directamente y no hay margen nuestro sobre el gasto. Es lo que hace que la palabra lock-in no signifique nada aquí: el día que dejes de trabajar con nosotros, la infraestructura sigue siendo tuya y sigue funcionando, junto con el repositorio y el código.
Lo que corre encima es lo de siempre: PostgreSQL con aislamiento por organización aplicado en la base de datos, secretos fuera del repositorio, integración continua antes de cada despliegue y inferencia con los datos personales anonimizados antes de salir. Se puede ver funcionando en Perizial.
Qué sostiene la infraestructura
Región elegida por los datos
No por precio. Cuando el dominio está regulado, la región aparece en el contrato con el cliente y en la auditoría.
Inferencia en Madrid
Vertex AI sobre Gemini en europe-southwest1. Datos y modelo permanecen dentro de la Unión Europea.
La cuenta cloud es tuya
El proyecto se despliega a nombre del cliente y el consumo se le factura directamente. No hay margen sobre el gasto en cloud.
PostgreSQL con aislamiento por tenant
Cuando el sistema sirve a varias organizaciones, la separación se aplica en la base de datos con Row-Level Security.
Secretos fuera del repositorio
Las credenciales viven en el gestor de secretos de la plataforma, no en el código ni en un fichero .env que acaba en un correo.
Minimización en la ingesta
Los documentos que entran no se persisten después del parseo: se procesan y se descartan.
CI antes de cada despliegue
Ningún cambio llega a producción sin pasar por integración continua. El desarrollo se hace con Claude Code y se revisa.
Coste visible
El gasto se ve en la cuenta del cliente, línea a línea, sin intermediación. Lo que no se ve, no se puede optimizar.
Dónde se puede ver funcionando
Perizial corre sobre esta infraestructura, en producción y con clientes de pago. Google Cloud, PostgreSQL con aislamiento por organización, inferencia en Vertex AI sobre Gemini en europe-southwest1 (Madrid) y datos personales anonimizados antes de llegar al modelo. Cuando un cliente de Perizial pregunta dónde se procesan los expedientes de sus peritajes, la respuesta es una región concreta y comprobable, no una categoría comercial.
Perizial: corriendo sobre esta infraestructura →
El SaaS que gestiona el gabinete pericial entero, en Google Cloud, con inferencia en Madrid y datos dentro de la UE.
Ingeniería: cómo trabajamos →
La línea de ingeniería a medida de CyberVaultLabs: cómo se define el alcance, qué cuesta y de quién es el código.
Preguntas frecuentes
- ¿En qué cloud corre vuestra infraestructura?
- En Google Cloud. Todas nuestras plataformas están desplegadas ahí, y la inferencia de IA corre en Vertex AI sobre Gemini, en la región europe-southwest1 (Madrid). Es lo que podemos enseñar funcionando: una consola, un proyecto y una región concretas, no un diagrama.
- ¿Trabajáis con AWS o con Azure?
- Nuestra experiencia en producción es Google Cloud, y no vamos a decir lo contrario. AWS y Azure son plataformas equivalentes para la mayoría de los casos, pero no operamos hoy sistemas en producción sobre ellas y afirmarlo sería exactamente el tipo de dato que no podríamos enseñar si nos lo pidieran. Si tu sistema ya vive en AWS o en Azure, lo honesto es decirlo antes de empezar: podemos construir contra él e integrarnos con él, y la decisión de moverlo o no es tuya, no una venta nuestra.
- ¿Qué significa residencia de datos en la UE?
- Que los datos y el procesamiento permanecen físicamente en regiones de la Unión Europea. En nuestro caso la inferencia corre en europe-southwest1, que es Madrid. No es una promesa comercial: es la región en la que está desplegado el proyecto, y se comprueba mirándola. Cuando el dominio está regulado, esa región aparece en el contrato y en la auditoría, y responder «está en la nube» no sirve.
- ¿Garantizáis un SLA de disponibilidad?
- No. Cyber Vault SL no firma hoy un SLA de disponibilidad con penalización, y anunciar un 99,9 % sin un contrato que lo respalde ni una medición pública que lo demuestre sería un número inventado. Lo que sí se puede enseñar es la arquitectura: dónde corre, cómo se despliega, dónde viven los datos y qué pasa cuando algo falla. Si tu caso exige un SLA contractual con penalizaciones, hay proveedores que lo firman y nosotros hoy no somos uno de ellos.
- ¿De quién es la cuenta cloud?
- Tuya. La infraestructura se despliega en una cuenta de Google Cloud a nombre del cliente, el consumo se factura directamente a esa cuenta y no hay margen nuestro sobre el gasto en cloud. Es también lo que evita el lock-in: si un día dejas de trabajar con nosotros, la infraestructura sigue siendo tuya y sigue funcionando.
- ¿Cómo se elige la región?
- Por dónde tienen que vivir los datos, no por dónde es más barato. En un dominio regulado la región es un requisito, no una preferencia de infraestructura: aparece en el contrato con el cliente y en la auditoría. Por eso la inferencia de nuestras plataformas corre en europe-southwest1 (Madrid) y no en la región más económica del catálogo.
- ¿Podéis montar y operar la infraestructura de mi sistema?
- Sí. Es una línea abierta: si tu empresa necesita un sistema propio, lo construimos contigo y lo desplegamos sobre una cuenta de Google Cloud a tu nombre, con la región elegida por dónde tienen que vivir tus datos. El consumo se te factura directamente y no hay margen nuestro sobre el gasto en cloud.
Servicios relacionados
Seguridad y cumplimiento →
Qué controles hacen que la residencia de datos sea algo más que una región bien elegida.
RAG empresarial privado →
La inferencia dentro de la UE, con los datos personales anonimizados antes de la llamada al modelo.
SaaS B2B multi-tenant →
Cómo se separan en la base de datos los datos de organizaciones que comparten infraestructura.
¿Hablamos de tu proyecto?
Escribe a [email protected] y cuenta qué proceso quieres automatizar, qué datos toca y con qué sistemas tiene que hablar. Con eso se puede responder si tiene sentido, qué alcance tendría y en qué rango de precio cae.