Resumen
- PREMI3NS ya no es solo un servicio futuro anunciado. S3NS lo puso a disposición general el 16 de octubre de 2025, y ANSSI calificó el servicio IaaS, PaaS y CaaS bajo SecNumCloud 3.2 el 17 de diciembre de 2025, con la decisión válida hasta el 17 de diciembre de 2028.
- Su geografía física está concentrada pero deliberadamente dividida: la región independiente
u-france-east1tiene tres zonas, cada una asociada a uno de tres centros de datos independientes en Francia. La documentación pública del producto indica que las funciones que requieren varias regiones no están disponibles. - Thales Cloud Sécurisé es el proveedor calificado y S3NS es la identidad comercial. La empresa se rige por la legislación francesa y está controlada por Thales; sus cuentas de 2024 registraron una participación de Thales del 95 % y de Google del 5 %, mientras que los estatutos actuales otorgan cinco puestos en el consejo con voto a los candidatos de Thales y un puesto de observador sin voto al otro accionista.
- El registro público respalda firmemente el control francés, un servicio en funcionamiento, un catálogo sustancial de servicios gestionados y un diseño a nivel de zona. No revela los tres operadores de las instalaciones, las ubicaciones exactas, las fuentes de suministro eléctrico, los contratos de operadores, la topología de la red troncal, los inventarios de repuestos ni los compromisos de respuesta de soporte al cliente.
- La calificación de evidencia resultante es Media. S3NS cuenta con pruebas regulatorias y operativas inusualmente sólidas para una nube joven, pero un comprador no puede inferir la recuperación de toda la región, la capacidad de conmutación por error utilizable o la reparación física rápida únicamente a partir de la calificación SecNumCloud o de un mapa de tres zonas.
Una promesa de nube se ha convertido en un servicio operativo
S3NS debe evaluarse ahora como un proveedor de infraestructura en funcionamiento, no como la propuesta que Francia debatió por primera vez en 2022. La secuencia es importante. La empresa abrió un programa de acceso temprano en enero de 2025, afirmó que más de 50 clientes y socios habían participado cuando cerró dicho programa, lanzó PREMI3NS endisponibilidad general el 16 de octubre de 2025, y recibió unacalificación de seguridad SecNumCloud 3.2dos meses después. Para abril de 2026, unanuncio de S3NS, SAP y Thalesindicaba que la empresa atendía a más de 60 clientes y ofrecía 30 servicios gestionados, con otros 30 previstos para el año siguiente.
Esos hitos resuelven una cuestión que antes requería cautela: PREMI3NS no es solo capacidad de diseño o un objetivo de certificación futuro. Existe un servicio en producción, un alcance calificado y una base de organizaciones que utilizan las ofertas de S3NS. La distinción entre las ofertas sigue siendo importante. CRYPT3NS, el producto anterior de controles locales construido en torno a Google Cloud estándar, se introdujo explícitamente sin el objetivo de obtener la calificación SecNumCloud. PREMI3NS es el entorno dedicado e independiente que ANSSI calificó.
Un cliente no puede transferir las garantías de un nombre de producto a otro simplemente porque ambos sean vendidos por S3NS.
Ladecisión de calificación de ANSSIes más precisa que un comunicado de prensa. Identifica al proveedor como THALES CLOUD SÉCURISÉ y al servicio como CLOUD DE CONFIANCE S3NS. Su alcance cubre servicios de infraestructura, plataforma y contenedores, no software como servicio. Elcatálogo actualde la agencia indica las fechas de calificación del 17 de diciembre de 2025 al 17 de diciembre de 2028. Eso establece un límite de aseguramiento claro: utilizar el servicio calificado, en sus condiciones calificadas, y verificar que cada producto dependiente realmente se encuentre dentro de ese límite.
El catálogo de servicios es lo suficientemente amplio como para crear una dependencia material. Lapágina de producto de PREMI3NSenumera máquinas virtuales, Kubernetes, almacenamiento de objetos y en bloque, bases de datos relacionales gestionadas, BigQuery, VPN, interconexión, DNS y servicios de seguridad. Estas no son herramientas periféricas. Pueden albergar funciones de identidad, transacciones, análisis, aplicaciones y copias de seguridad que se vuelven difíciles de desenredar después de que una organización estandarice su modelo operativo en torno a ellas.
Por eso la capa física es importante ahora. Una hoja de ruta puede juzgarse por su plausibilidad. Una nube en producción debe juzgarse por lo que sigue siendo utilizable cuando un rack pierde energía, una zona queda aislada, un operador falla, una actualización se retiene, una cola de soporte se llena o un cliente necesita irse.
El proveedor es Thales Cloud Sécurisé, no una alianza abstracta
El nombre S3NS describe una asociación y una marca, pero el proveedor legal es concreto. El registro mercantil francés identifica a THALES CLOUD SECURISE, SIREN 908 211 980, como una sociedad por acciones simplificada francesa creada en 2021. Su domicilio social actual está en el 26 rue de Montholon en París. Losestatutos actualizados de la empresamuestran un capital de 3,3 millones de euros a abril de 2026.
El control es más informativo que la descripción vaga "Thales y Google cloud". Lascuentas financieras de 2024de la empresa indican que Thales poseía el 95 % de las acciones y Google el 5 % a finales de año. Los estatutos de 2026 contemplan cinco directores con derecho a voto propuestos por Thales y un observador sin voto designado por el otro accionista. También excluyen a ese observador del acceso a los datos de los clientes y a la información sensible sobre seguridad física y lógica. En un testimonio ante una comisión parlamentaria francesa en 2026, el director de asuntos públicos de Google describió que Google tenía un puesto de observador sin voto ni veto en el consejo. Los estatutos son la prueba más útil porque detallan la estructura en lugar de comprimirla en un eslogan.
Esto no significa que Google no sea importante. Las cuentas de 2024 indican que S3NS y Google firmaron el acuerdo que rige las relaciones técnicas y comerciales para la nube de confianza en diciembre de 2024. Google suministra la tecnología de nube subyacente y su evolución. La propuesta de valor de S3NS es que Thales Cloud Sécurisé controla el entorno dedicado, el personal, las claves, las operaciones y el despliegue de actualizaciones, al tiempo que se beneficia de la ingeniería de software de Google.
Ese límite ha superado una exigente calificación francesa. Sigue siendo un límite de proveedor. Si las actualizaciones de software se detienen, las condiciones de licencia cambian, el acceso a la documentación se reduce o una generación de hardware deja de estar disponible, el control legal del entorno en funcionamiento no fabrica una pila tecnológica de reemplazo. A la inversa, la dependencia tecnológica no implica que Google pueda leer los datos de los clientes o administrar PREMI3NS. La evaluación significativa mantiene ambos hechos a la vez: S3NS controla el servicio calificado; Google sigue siendo un proveedor tecnológico estratégico.
El registro corporativo también aporta evidencia del desarrollo. S3NS informó de 126 empleados a finales de 2024, tras incorporar 51 durante el año, incluidas 40 incorporaciones a los equipos técnicos. Su balance registró 14,2 millones de euros en activos tangibles en construcción, frente a los 3,7 millones del año anterior. Los ingresos aumentaron a 4,94 millones de euros, mientras que la empresa registró una pérdida anual de 942.293 euros. Estas cifras describen a un operador en fase de inversión antes de la disponibilidad general y la calificación.
No prueban por sí solas la capacidad del cliente ni la debilidad financiera, pero muestran que el servicio dependía de una construcción y dotación de personal sustanciales antes del lanzamiento.
Una región francesa contiene tres dominios de fallo físicos
PREMI3NS es físicamente más limitado de lo que sugiere la palabra nube. Ladescripción general actual de Cloud de Confianceindica que es un universo de nube autónomo con una región,u-france-east1. Esa región tiene tres zonas:u-france-east1-a,u-france-east1-byu-france-east1-c. El material de ventas de S3NS afirma que la región comprendetres centros de datos independientes en Francia. Un material anterior de S3NS los situaba en la región de París y describía salas dedicadas cercanas a los tres centros de datos de Google en Francia, con racks, servidores y redes aislados física y lógicamente.
Esta es una evidencia física significativa. Indica algo más que tres etiquetas aplicadas a una sola sala de servidores. El proveedor afirma que las zonas se corresponden con centros de datos independientes, y su documentación indica a los clientes que traten cada zona como un dominio de fallo distinto. Las aplicaciones distribuidas entre zonas pueden, por tanto, diseñarse para sobrevivir a algunos fallos de hardware, energía, refrigeración o red en una zona.
Pero una zona no es automáticamente un duplicado completo de cada servicio. Las instancias de cómputo y los discos zonales permanecen vinculados a una zona. Algunos servicios regionales se replican entre zonas, mientras que otros productos gestionados tienen sus propias semánticas de durabilidad y disponibilidad. Un cliente que lanza una máquina virtual y adjunta un disco zonal no ha obtenido continuidad en tres sitios simplemente por elegir una región de tres zonas. Ha colocado dos recursos zonales en un dominio de fallo.
La carga de la arquitectura recae en el cliente. El cómputo necesita al menos otra instancia en otra zona, comprobaciones de estado y un mecanismo de desvío de tráfico. Los sistemas con estado necesitan un modelo de replicación cuyo comportamiento de consistencia y recuperación coincida con la aplicación. La identidad, los secretos, el registro y los controles de despliegue también deben sobrevivir al mismo fallo de zona. Las copias de seguridad deben ser restaurables cuando el servicio principal esté afectado, en lugar de existir simplemente como otro objeto dentro del límite operativo afectado.
S3NS no publica las direcciones ni los operadores de las tres instalaciones en el material aquí enlazado. Esa restricción es comprensible para una plataforma diseñada para cargas de trabajo sensibles. También significa que un comprador no puede determinar de forma independiente si los sitios comparten una llanura aluvial, una subestación eléctrica, un corredor de fibra, un propietario, un contratista de mantenimiento o un proveedor de asistencia remota únicamente a partir de los nombres de las zonas.
"Centros de datos independientes" es una afirmación útil; el riesgo de correlación sigue siendo una cuestión de diligencia debida que debe responderse bajo confidencialidad.
Tres zonas no crean una segunda región
La mayor limitación arquitectónica se expone claramente en la documentación de S3NS: Cloud de Confiance tiene actualmente una región, ylas funciones que requieren varias regiones no están disponibles. Esto hace que la diferencia entre alta disponibilidad y recuperación ante desastres sea especialmente importante.
Tres zonas pueden proteger contra un evento a nivel de servidor, rack o sitio si la aplicación las utiliza correctamente. No protegen contra todos los eventos que afectan a la región como una unidad. Los fallos de identidad regional, plano de control, software, enrutamiento u operativos pueden cruzar los límites de las zonas. Un evento grave de energía o fibra metropolitano también puede crear una presión correlacionada incluso cuando los edificios están físicamente separados. Lo mismo ocurre con una respuesta de seguridad que desactive intencionadamente un servicio compartido en todo el entorno.
La nube pública de Google normalmente permite a un cliente emparejar regiones. PREMI3NS no ofrece actualmente ese patrón dentro de su universo calificado. Sus recursos "globales" son globales solo dentro del entorno autónomo de S3NS y se resuelven en la única región francesa; no son réplicas distribuidas por la nube mundial de Google. Esta es una consecuencia necesaria de la estricta separación jurisdiccional y operativa, pero cambia el cálculo de la recuperación.
Un cliente con el requisito de sobrevivir a la pérdida deu-france-east1necesita un segundo entorno fuera de PREMI3NS. Este podría ser una infraestructura local, otro proveedor francés o europeo calificado, un entorno de recuperación en frío controlado por separado o un nivel de servicio menos sensible con un límite de datos cuidadosamente definido. Cada opción introduce sus propios problemas: replicación de datos, custodia de claves, compatibilidad de software, capacidad de red, acceso del operador y el estatus legal de la copia de recuperación.
Esto no es un argumento en contra de PREMI3NS. Una sola región puede ser el límite adecuado para datos sensibles, especialmente cuando la alternativa otorga a un proveedor extranjero control operativo directo. Es un argumento contra confundir tres zonas con recuperación geográfica ante desastres. La decisión corresponde al análisis de impacto en el negocio: qué cargas de trabajo pueden aceptar una interrupción regional, cuáles deben recuperarse en otro lugar y cuántos datos o funcionalidad pueden perderse durante esa migración.
La propia documentación del proveedor apunta en la dirección correcta al indicar a los clientes que distribuyan las aplicaciones entre zonas. Un contrato maduro debería continuar con esta idea. Debería definir si S3NS tiene un plan de restauración regional, cómo se recuperan la configuración y los metadatos del cliente tras una pérdida catastrófica, y qué asistencia está disponible para reconstruir fuera de la plataforma si la región no puede volver a estar operativa dentro del plazo del cliente.
El aislamiento físico cambia quién puede tocar las máquinas
La afirmación central de ingeniería de S3NS no es simplemente que los datos se almacenan en Francia. Es que el equipo está aislado y las personas que pueden operarlo están bajo el control de S3NS. La empresa describe racks, servidores y equipos de red dedicados, controles de acceso físico, vigilancia y detección de intrusiones, junto con identidades separadas, raíces de confianza, cifrado y límites de red. Elanuncio de la calificaciónafirma que solo los empleados de S3NS administran el servicio y que la tecnología y las actualizaciones de Google entran en un área de cuarentena para su análisis y validación antes de su despliegue en producción.
Esos controles abordan varios riesgos reales. Un administrador remoto empleado por Google no debería poder ingresar al entorno. Se supone que una actualización de software no fluye directamente del proveedor de tecnología a producción. El control criptográfico y la identidad de producción residen en el operador francés. El servicio calificado también debe cumplir los requisitos de SecNumCloud en materia de seguridad física, administración aislada, gestión de incidentes, continuidad, subcontratación y protección frente a legislación no europea.
Sin embargo, la separación física crea una infraestructura operativa que S3NS debe mantener por sí misma. Alguien tiene que recibir servidores, validar el firmware, cablear los racks, reemplazar las unidades fallidas, rotar los módulos de seguridad de hardware y coordinar el trabajo dentro de la sala de datos. Una reparación que realizaría la flota global de un hiperescalar se convierte en una responsabilidad de S3NS o en una actividad subcontratada estrictamente controlada. El operador necesita suficiente personal, derechos de acceso, repuestos y acuerdos con proveedores en los tres sitios.
Los documentos públicos no indican el número de racks, las generaciones de servidores, la asignación total de energía, el margen de refrigeración, las existencias de repuestos o la cobertura de técnicos locales para cada zona. Tampoco identifican qué trabajo de las instalaciones es realizado por empleados de S3NS y cuál permanece en manos de los propietarios o contratistas especializados. SecNumCloud establece que los controles fueron evaluados dentro del alcance calificado. No proporciona a los clientes un programa de capacidad ni una garantía de tiempo de reparación para cada componente.
Esa infraestructura operativa oculta es la sustancia económica del servicio. Los clientes pagan para que S3NS convierta equipos, arrendamientos, energía, tránsito, licencias, controles de seguridad y mano de obra especializada en servicios de nube medidos. El margen entre la infraestructura instalada y la demanda de los clientes determina si un rack fallido produce una evacuación rutinaria o una escasez de capacidad. El contrato de piezas determina si un chasis de red fallido se reemplaza en horas o espera una logística internacional. Ninguno de estos resultados es visible en un catálogo de productos.
La soberanía del software tiene un reloj de mantenimiento
PREMI3NS está diseñado para impedir que Google administre el entorno del cliente o lo apague de forma remota. Eso es diferente de eliminar la dependencia de la ingeniería de Google. Las bases de datos gestionadas, la orquestación, el almacenamiento y los servicios de análisis siguen siendo sistemas de software complejos que requieren correcciones de seguridad, trabajo de compatibilidad y habilitación de hardware. Por lo tanto, la cuestión no es solo si S3NS puede mantener el código actual en funcionamiento tras una ruptura con el proveedor.
Es cuánto tiempo puede funcionar de forma segura mientras las vulnerabilidades, los certificados, las dependencias y los requisitos de los clientes continúan cambiando.
Losrequisitos de SecNumCloud 3.2abordan explícitamente la autonomía operativa cuando un proveedor depende de un tercero. El director de ANSSI subrayó posteriormente en público que la calificación protege contra el acceso directo no europeo y un cierre específico para un cliente, pero no significa que no haya dependencia tecnológica. Esa es la distinción correcta. La soberanía sobre la operación no es lo mismo que la independencia indefinida de cada proveedor.
Google afirma que su diseño de nube dedicada permite al socio local supervisar, bloquear y revertir las actualizaciones, y que puede seguir funcionando durantehasta 12 meses después de que se corte la conexión con Google. La misma publicación de Google identifica a PREMI3NS como la implementación francesa. Esta es una afirmación de continuidad significativa, pero la redacción pública describe una capacidad de diseño en lugar de una garantía de recuperación específica para el cliente. Un comprador debe establecer qué servicios de PREMI3NS están cubiertos, qué significa "operar" durante el período, qué actualizaciones de seguridad siguen estando disponibles y qué sucede al final del mismo.
El mecanismo de cuarentena conlleva su propia contrapartida. La revisión de las actualizaciones reduce el riesgo de que una versión comprometida o inadecuada entre en el entorno de confianza. También puede crear un retraso en las funciones y una cola cuando llegan muchos cambios de origen a la vez. S3NS necesita suficiente profundidad de ingeniería para evaluar, probar, aprobar o rechazar las actualizaciones sin dejar vulnerabilidades críticas sin resolver. Los clientes necesitan aviso de las diferencias con Google Cloud estándar para que los scripts de despliegue y las suposiciones de los servicios gestionados no se desvíen silenciosamente.
La documentación de S3NS ya advierte que Cloud de Confiance es un producto separado con un subconjunto de productos de Google Cloud y diferentes puntos finales, incluyendos3nsapis.fren lugar degoogleapis.com. Eso es evidencia de una separación real. También es evidencia de que la migración no es un simple cambio de región. Los propietarios de aplicaciones deben probar el código, las bibliotecas, las suposiciones de identidad, la disponibilidad de servicios y los procedimientos operativos en el propio universo de S3NS.
La conectividad comienza donde el cliente entra en la nube
Un servidor soberano al que no se puede llegar no es un servicio. PREMI3NS admite acceso a Internet público, Cloud VPN y Cloud Interconnect, y esas rutas tienen diferentes límites de fallo y confianza. Ladocumentación de conectividad de reddescribe VPN como tráfico cifrado a través de Internet público e Interconnect como conectividad dedicada o de socio entre una red de cliente y la nube.
Para una infraestructura de producción, el diseño de acceso debe coincidir con el diseño de zonas. Dos máquinas virtuales en zonas separadas siguen dependiendo de un solo enrutador de cliente si se accede a ambas a través de un túnel. Dos circuitos de interconexión aún pueden compartir una entrada de edificio, un operador, un sistema óptico o un conducto metropolitano. Un diagrama resiliente necesita diversidad en cada punto de entrega: enrutadores del cliente, proveedores de operadores, conexiones cruzadas, dominios de borde de S3NS, sesiones BGP y suficiente ancho de banda de conmutación por error para transportar la carga crítica.
Ladocumentación de Partner Interconnectde S3NS ilustra este punto. Indica que un diseño del 99,9 % necesita dos conexiones redundantes en diferentes dominios de disponibilidad de borde, mientras que su patrón genérico del 99,99 % requiere cuatro conexiones divididas en dos áreas metropolitanas y dos regiones. Dado que PREMI3NS actualmente solo tiene una región, ese patrón de dos regiones no se puede implementar completamente dentro del universo actual de S3NS. Los clientes no deben asumir que la compra de cuatro circuitos dentro de París crea el mismo aislamiento de fallos.
HA VPN tiene una topología diferente. S3NS documenta una configuración del 99,99 % cuando ambas interfaces de la puerta de enlace gestionada se conectan a través de túneles coincidentes con el lado del par. Pero la disponibilidad de la conexión de extremo a extremo aún depende de las puertas de enlace físicas del cliente, los proveedores de Internet o las interconexiones, la política de enrutamiento y la carga de trabajo alojada. Una cifra de nivel de servicio del lado de la nube no cubre un solo enrutador en la oficina del cliente.
El rendimiento también es parte de la recuperación. Una interconexión dimensionada para la replicación normal de bases de datos puede ser demasiado pequeña para resembrar el almacenamiento después de un fallo. Una VPN que transporta cómodamente el tráfico de gestión puede colapsar cuando se convierte en la única ruta para las transacciones del cliente. Los ejercicios de recuperación deben medir las tasas de transferencia bajo la topología degradada, no utilizar la velocidad del puerto como indicador.
La capa de operadores y red troncal sigue siendo opaca
La documentación de PREMI3NS indica que su red premium transporta el tráfico en la red de Cloud de Confiance y selecciona las rutas BGP hacia las redes de peering o tránsito. También permite a los clientes traer rangos IPv4 e IPv6 elegibles, sujetos a la validación de la propiedad y la autorización de origen de ruta. Estas son capacidades maduras de red en la nube. No revelan los proveedores reales ni las rutas físicas detrás del borde de S3NS.
El material público enlazado en este artículo no nombra a los operadores de tránsito, los edificios de interconexión, los puntos de intercambio de Internet, los proveedores de fibra troncal ni las relaciones de servidor de ruta utilizadas por PREMI3NS. No publica un ASN de plataforma, una lista completa de prefijos de proveedor ni un mapa que un cliente pudiera utilizar para establecer la diversidad de rutas. Las direcciones expuestas por la carga de trabajo de un cliente también pueden depender de si el cliente utiliza espacio asignado por S3NS, trae sus propias direcciones, entra a través de un socio o mantiene el servicio privado.
La opacidad no es prueba de fragilidad. Los proveedores sensibles a menudo limitan la divulgación de la topología, y una red virtual distribuida no puede reducirse a un icono de enrutador. Significa que la frase "múltiples rutas" necesita evidencia bajo confidencialidad. Los compradores deben preguntar si las tres zonas tienen entradas de fibra físicamente separadas, si los enlaces entre zonas comparten conductos, dónde terminan las interconexiones dedicadas y si dos productos de operador nombrados en última instancia utilizan la misma red mayorista.
También deben preguntar cómo valida S3NS la seguridad del enrutamiento. Los prefijos proporcionados por el cliente requieren autorizaciones de origen de ruta correctas, objetos de enrutamiento precisos y un traspaso controlado. El espacio del proveedor necesita su propia seguridad de origen y filtrado. Una política de ruta equivocada puede retirar un servicio saludable de Internet incluso mientras cada rack permanece alimentado.
El límite se extiende más allá de S3NS. Una aplicación pública depende del DNS, la emisión de certificados, el registro de dominios, la distribución de contenido, la identidad y las redes de usuarios ascendentes. Algunos de esos servicios pueden estar fuera de PREMI3NS o fuera de Francia. Alojar la carga de trabajo principal en una región calificada no traslada automáticamente todo el servicio a la misma jurisdicción o dominio de fallo.
La capacidad instalada no es capacidad de conmutación por error
S3NSpromocionó 30 servicios gestionados en febrero de 2026y enumera las máquinas virtuales con GPU H100 entre sus opciones de cómputo. Eso demuestra amplitud, no cantidad. Los documentos públicos no indican cuántos procesadores, GPU, dispositivos de almacenamiento o puertos de red están instalados en cada zona, cuánto está reservado o cuánto margen queda después de la pérdida de una zona.
Esto es importante porque la capacidad de la nube se vende dos veces en la imaginación del cliente. La primera venta es la elasticidad: los recursos aparecen bajo demanda. La segunda es la redundancia: otra zona aparece lista cuando la primera falla. Ambas promesas se basan en el mismo inventario físico. Si muchos clientes solicitan instancias de reemplazo durante un evento zonal, la capacidad sobrante puede desaparecer rápidamente. Una cuota que permite un recurso en condiciones normales no garantiza que habrá hardware equivalente disponible durante una situación de estrés regional.
El equipo especializado agrava la restricción. Las cargas de trabajo de GPU pueden depender de un acelerador, controlador y familia de máquinas en particular que no esté distribuido uniformemente en todas las zonas. Las bases de datos de gran memoria y el almacenamiento de alto rendimiento tienen límites de ubicación similares. Un cliente puede construir un diseño nominal multizona que en realidad no puede reiniciarse en otro lugar con la misma configuración.
La medida correcta es la capacidad utilizable después del fallo elegido, no la capacidad instalada antes del mismo. Para servicios críticos, los clientes necesitan capacidad reservada o priorizada contractualmente, confirmación de la ubicación y evidencia periódica de que la zona de reserva puede aceptar la carga de trabajo. También necesitan una estrategia de degradación acordada: instancias más pequeñas, análisis reducidos, trabajos por lotes pausados o un servicio de transacciones mínimo cuando no se pueda restaurar la capacidad total.
S3NS tiene buenas razones para no publicar el recuento de su flota. Los competidores y atacantes valorarían la información, y los recuentos cambian rápidamente. Una garantía confidencial puede dar a los compradores lo que necesitan: clases de capacidad, límites de evacuación probados, plazos de entrega para hardware poco común y las reglas de prioridad utilizadas durante la contención. Sin esa evidencia, "tres zonas" describe ubicaciones, no la cantidad de servicio disponible después de perder una.
La mano de obra de soporte es parte de la infraestructura
El programa de acceso temprano expuso un detalle útil sobre el modelo operativo de S3NS. La empresa dijo que participaron ingenieros de fiabilidad del sitio, equipos de ciberseguridad, personal del centro de datos, soporte, gestores de cuentas técnicas e ingenieros de clientes. Esta es una evidencia creíble de una organización construida para operar más que un portal de autoservicio. La descripción general actual de la plataforma también afirma que S3NS, no Google Cloud, es responsable de la gestión de la infraestructura y el soporte.
Esta responsabilidad local es fundamental para la reivindicación de soberanía. Un incidente de cliente no debería requerir que un administrador de Google ingrese al entorno. También concentra la escalada en S3NS. Si un defecto en una base de datos gestionada requiere experiencia del proveedor, S3NS tiene que reproducir el problema, controlar qué información sale del entorno, coordinarse con Google y devolver una solución segura. El cliente depende de la calidad de esa capa de traducción.
El material público no proporciona una matriz de soporte completa con definiciones de gravedad, tiempos de respuesta inicial, objetivos de restauración, condiciones de escalada telefónica y compensación por nivel de servicio. El anuncio de disponibilidad general indica que los acuerdos de nivel de servicio contractuales acompañaron al lanzamiento, pero no los reproduce. Por lo tanto, los compradores necesitan el contrato, no el lenguaje de lanzamiento.
El reloj de reparación debe descomponerse. La detección es el tiempo hasta que S3NS o el cliente notan un fallo. La propiedad es el tiempo hasta que alguien con autoridad lo acepta. El diagnóstico identifica si el problema pertenece a la configuración del cliente, al servicio gestionado, a la red de S3NS, a una instalación o a una actualización tecnológica. El acceso es el retraso hasta que un ingeniero puede entrar en el sitio relevante. La reparación incluye piezas, aprobación de cambios y validación. La recuperación no está completa hasta que la aplicación, los datos y el trabajo en cola vuelven a ser utilizables.
Un objetivo de restauración combinado oculta estas transiciones. También oculta a terceros. Los servicios remotos de las instalaciones, los técnicos de fibra, los proveedores de hardware y los especialistas de Google pueden estar involucrados sin operar directamente el entorno del cliente. Un cliente debe saber qué parte puede detener el reloj, qué parte le habla durante un incidente grave y si el canal de estado sigue siendo accesible si la identidad o la consola de S3NS se ven afectadas.
Un acuerdo de nivel de servicio no construye una aplicación resiliente
S3NS describió la disponibilidad general como la incorporación de acuerdos de nivel de servicio formales y preparación para producción. Esa es una evidencia comercial necesaria. Un SLA sigue siendo una promesa limitada en torno a una métrica de servicio definida. No puede convertir una máquina virtual zonal en regional, añadir una segunda región de PREMI3NS o reparar una arquitectura de cliente que envía todas las rutas a través de una sola puerta de enlace.
La diferencia se vuelve nítida durante un incidente compuesto. Supongamos que una zona pierde energía, la aplicación conmuta por error y la base de datos superviviente alcanza un límite de conexión impuesto por el cliente. El servicio de infraestructura puede cumplir su medida de disponibilidad mientras la aplicación no está disponible. Si el cliente no ha distribuido la identidad, los secretos o la monitorización, el proveedor puede restaurar la infraestructura antes de que el negocio pueda restaurar el servicio.
Los créditos de servicio son igualmente limitados. Ajustan una factura después de un fallo que cumple los requisitos. No reembolsan los servicios públicos perdidos, el trabajo médico retrasado, las transacciones financieras fallidas o la mano de obra de migración de emergencia. Para sistemas sensibles, el lenguaje contractual útil cubre la comunicación de incidentes, la integridad de los datos, la asistencia, la preservación de pruebas, las prioridades de recuperación y el soporte de terminación, no solo un porcentaje de tiempo de actividad mensual.
Las exclusiones de mantenimiento necesitan la misma atención. Un proveedor que opera un suministro de software en cuarentena tiene que parchear y actualizar. Los clientes necesitan saber cuánto aviso se aplica, si las zonas se mantienen secuencialmente, qué sucede cuando un cambio de emergencia no puede esperar y si una reversión es técnicamente posible. Deben diseñar las aplicaciones para tolerar el comportamiento de mantenimiento que el contrato permite.
El canal de estado es otra dependencia. La documentación de S3NS remite a los clientes a un panel de salud del servicio de Cloud de Confiance, pero un canal útil para incidentes graves debe funcionar fuera de la consola y del plano de identidad fallidos. Los contactos designados, las rutas de notificación independientes y una cadencia de actualizaciones son capacidad operativa: determinan la rapidez con la que los clientes pueden elegir entre esperar, conmutar por error o invocar un plan de recuperación regional.
SecNumCloud es una garantía sólida, no un seguro universal
La calificación SecNumCloud es la evidencia pública más sólida que respalda a PREMI3NS. El marco de ANSSI cubre mucho más que la ubicación de los datos. Sus requisitos incluyen seguridad física, control de acceso, administración aislada, registro, gestión de vulnerabilidades, criptografía, continuidad, gestión de proveedores, reversibilidad y protección frente a legislación no europea. Laspreguntas frecuentes sobre la calificaciónde la agencia explican que los datos del cliente, los directorios de administración, los directorios de usuarios, los registros, las autoridades raíz y las copias de seguridad deben cumplir controles territoriales, y que se evalúa la autonomía operativa continua.
La decisión también establece que S3NS satisface la recomendación R9 de la doctrina de nube del Estado francés y ofrece protección frente a la legislación extraeuropea. Este es un resultado consecuente para los organismos públicos y las organizaciones reguladas. Ladoctrina "Cloud at the Centre"de Francia orienta las cargas de trabajo estatales especialmente sensibles hacia nubes comerciales calificadas que estén protegidas del acceso no autorizado por parte de autoridades de terceros países.
La calificación no significa que cada uso de S3NS sea automáticamente conforme o resiliente. La decisión de ANSSI condiciona el uso a las recomendaciones del marco. Los clientes aún configuran identidades, redes, almacenamiento, cifrado, registro y aplicaciones. Pueden crear una base de datos de una sola zona, exponer un servicio inseguro o copiar datos a un sistema externo no calificado.
El visado tampoco cubre todos los productos vendidos bajo el nombre de S3NS. Cubre el servicio Cloud de Confiance designado como IaaS, PaaS y CaaS. CRYPT3NS se comercializó explícitamente como un paso intermedio que no buscaba la calificación SecNumCloud. Las aplicaciones SaaS de socios que se ejecutan en PREMI3NS requieren su propio análisis de alcance. Un sustrato calificado no califica automáticamente el software y las prácticas operativas que se ejecutan sobre él.
Por último, el visado tiene fechas. Tiene una vigencia de tres años y depende del cumplimiento continuo. Los cambios materiales legales, organizativos o técnicos deben gestionarse dentro de las obligaciones de calificación. La contratación debe registrar el número de decisión, el alcance, la caducidad y cualquier condición posterior, en lugar de utilizar "SecNumCloud" como una insignia atemporal.
Los anuncios de clientes muestran demanda, no recuperación probada
S3NS ha nombrado clientes en seguros, salud, finanzas, industria y servicios. Su anuncio de calificación citó a MGEN, Matmut, AGPM, Thales, Birdz, Qonto, BConnect y Club Med. Elcaso de MGENes especialmente relevante porque la aseguradora describió una plataforma destinada a dar servicio a hasta seis millones de personas. Un anuncio de abril de 2026 indicó que SAP RISE Private Cloud Edition se desplegaría en PREMI3NS para Thales en la segunda mitad de 2026, cubriendo áreas de negocio principales como finanzas, cadena de suministro, fabricación y compras.
Estos nombres respaldan la conclusión de que S3NS está sirviendo o preparando cargas de trabajo reales. También indican quién soporta las consecuencias de los fallos: asegurados, usuarios de servicios de salud, empleados, proveedores, equipos financieros y operaciones industriales. Esa consecuencia eleva el valor de un fuerte control francés al tiempo que aumenta la necesidad de una recuperación práctica.
Un anuncio de cliente no es un historial de incidentes. Rara vez indica qué cargas de trabajo están ya en producción, cuántos datos contienen, si abarcan las tres zonas, qué tiempo de recuperación se demostró o si se ejerció una salida regional. "Elegido por" puede describir un contrato, un programa de migración, una prueba de adopción temprana o una infraestructura de producción. Cada uno tiene un peso probatorio diferente.
Por lo tanto, el uso correcto de tales anuncios es modesto. Validan la tracción del mercado y muestran que organizaciones exigentes han realizado sus propias evaluaciones. No transfieren la garantía no revelada de esas organizaciones a otro comprador. Un nuevo cliente debe probar su propia aplicación, red, datos y cadena de soporte.
El propio S3NS también es cliente de proveedores. Los propietarios de centros de datos, las empresas de servicios públicos, los operadores, los fabricantes de servidores, los distribuidores de componentes y Google están detrás del servicio incluso cuando no pueden administrarlo. El modelo de confianza es más fuerte cuando cada dependencia está limitada, es reemplazable y probada. Es más débil cuando el cliente trata el contrato de S3NS como el nodo final de la cadena.
La localidad de los datos necesita un mapa de cada copia
PREMI3NS ofrece una propuesta clara de ubicación principal: los datos y las cargas de trabajo permanecen en Francia en un entorno dedicado de S3NS. Esto es más sólido que asumir la ubicación a partir de una dirección de facturación o un resultado de geolocalización de IP. La arquitectura también mantiene la identidad de producción, el control de claves, la administración y el soporte bajo la autoridad del operador francés.
Los clientes aún necesitan mapear cada categoría de información. Los datos primarios, las réplicas, las copias de seguridad, las instantáneas, los registros, los archivos adjuntos de soporte, los registros de facturación, la telemetría, las claves y los metadatos de identidad no comparten necesariamente el mismo ciclo de vida. SecNumCloud impone requisitos territoriales dentro del servicio calificado, pero un cliente puede enviar registros a una plataforma externa, abrir un caso de soporte que contenga datos sensibles o replicar una base de datos a otra jurisdicción.
El diseño de una sola región hace que la ubicación de las copias de seguridad sea particularmente importante. Una copia de seguridad copiada en tres zonas puede sobrevivir a un fallo de dispositivo o sitio, pero permanece dentro deu-france-east1. Una copia fuera de la región mejora la recuperación ante desastres, pero puede salir del límite calificado exacto que la organización seleccionó. Algunas cargas de trabajo pueden justificar el almacenamiento en frío cifrado en otro proveedor calificado; otras pueden estar obligadas legal u operativamente a permanecer en el entorno de S3NS. La respuesta depende de los datos y del objetivo de recuperación.
La gestión de claves debe seguir el mismo mapa. Una copia de recuperación es inútil si sus claves están atrapadas en la región fallida. Una clave copiada en otro lugar puede crear una nueva ruta de acceso que socave el control original. Por lo tanto, el diseño de la recuperación necesita disponibilidad independiente para las claves, las identidades, la configuración y las personas autorizadas a utilizarlas, con controles al menos tan deliberados como los que rodean a los datos.
La localidad también cambia la latencia y el área de servicio. Los tres centros de datos están en Francia, y las descripciones anteriores de S3NS los sitúan en la región de París. Los usuarios europeos pueden experimentar una buena latencia, pero una región francesa no está automáticamente cerca de cada sucursal, fábrica o territorio de ultramar. La red de acceso y el diseño de la aplicación determinan el rendimiento experimentado. Una organización multinacional también tiene que decidir si todos los usuarios y datos pertenecen a la jurisdicción francesa o si PREMI3NS debe contener solo el subconjunto sensible.
La migración es el mecanismo de recuperación final
S3NS promueve la continuidad con la tecnología de Google Cloud, y eso puede reducir el esfuerzo de migración para los clientes que ya utilizan API y servicios gestionados familiares. No hace que las plataformas sean idénticas. El universo dedicado tiene diferentes puntos finales, un conjunto de servicios más reducido, una sola región y controles operativos basados en la calificación. La migración a PREMI3NS es un programa de ingeniería planificado; la migración de salida también lo será.
Una guía de migración de S3NS señala que el tiempo de transferencia depende del volumen de datos y del ancho de banda de la red. Esta simple afirmación se vuelve severa durante una interrupción. Mover 500 terabytes a través de una ruta que ofrezca 5 gigabits por segundo de forma sostenida lleva más de nueve días antes de considerar la sobrecarga del protocolo, los reintentos, la validación y el traspaso de la aplicación. Si el servicio de origen está degradado, el rendimiento real puede ser mucho menor. Si el destino utiliza una base de datos gestionada diferente, la conversión puede dominar el copiado.
Las normas francesas y europeas están reforzando la posición del cliente. El artículo 28 de laley SREN francesaexige que los servicios en la nube admitan la interoperabilidad segura, la portabilidad de los datos exportables y los activos digitales, así como las interfaces y la información necesarias para llevarla a cabo. Larecomendación de Arcep de 2025se centra en la transparencia del cambio y las interfaces estables. La Ley de Datos de la UE aplica obligaciones de cambio y elimina gradualmente los cargos por cambio.
La portabilidad legal no garantiza la equivalencia operativa. Los datos exportables pueden excluir la propiedad intelectual del proveedor. Una aplicación Kubernetes puede migrar más fácilmente que una carga de trabajo construida en torno a BigQuery, el comportamiento de Cloud SQL, la identidad del proveedor y la monitorización propietaria. Incluso cuando los registros se exportan limpiamente, las políticas, las colas, el historial de eventos, el estado criptográfico y los paneles operativos pueden no hacerlo.
Por lo tanto, los clientes deben mantener un pequeño pero completo despliegue de recuperación en otro lugar. Debe restaurar datos reales, recrear la identidad y las redes, y demostrar que el negocio puede operar a un nivel mínimo definido. El ejercicio debe registrar la velocidad de transferencia, los fallos de conversión, los metadatos faltantes y el personal necesario. Un plan de salida que solo existe como lenguaje contractual no es capacidad sobrante.
Las vías de fallo creíbles son ordinarias
S3NS atrae la atención debido a cuestiones geopolíticas y legales, pero los fallos más probables son eventos de infraestructura familiares. Un componente de energía falla. Un dispositivo de almacenamiento produce errores. Una fibra se corta. Una ruta BGP se retira. Un certificado caduca. Una actualización de un servicio gestionado cambia el comportamiento. Un ticket de soporte se clasifica erróneamente. El pago o el estado de la cuenta de un cliente interrumpe el acceso. Una migración dura más que su ventana aprobada.
Un fallo de rack o servidor debería ser contenido por la redundancia local, pero solo si el servicio y la ubicación del cliente lo admiten. Un fallo de zona debería ser contenido por una arquitectura multizona y una capacidad de supervivencia adecuada. Un fallo regional no tiene una segunda región de PREMI3NS y, por lo tanto, invoca el diseño de recuperación externa del cliente. Un fallo de origen o interconexión invoca diversas rutas de red. Una interrupción del suministro de software invoca la autonomía y la estrategia de actualización de S3NS.
Una disputa contractual o de facturación invoca la continuidad administrativa y los derechos de exportación.
Cada vía afecta a una población diferente. Un servicio de análisis aislado puede retrasar los informes internos. Un fallo de identidad puede impedir que cada aplicación se inicie, incluso mientras el cómputo permanece saludable. La pérdida de una plataforma de salud puede afectar la administración de la atención y el acceso de los pacientes. La pérdida de un ERP industrial puede bloquear las compras, la fabricación y el envío. La dependencia debe clasificarse por función empresarial, no por la importancia aparente del nombre del recurso en la nube.
Los fallos compuestos merecen una atención especial. Una interrupción de zona durante el mantenimiento deja menos capacidad sobrante. Un incidente cibernético puede desactivar la automatización al tiempo que aumenta la demanda de soporte manual. Un problema de red regional puede ralentizar la misma transferencia de copia de seguridad destinada a la recuperación. Una disputa con un proveedor puede coincidir con una vulnerabilidad de seguridad urgente. La resiliencia es la capacidad de operar a través de esas combinaciones, no la presencia de tres casillas en un diagrama de arquitectura.
S3NS ha construido un control inusualmente sólido en torno a una nube francesa basada en tecnología no francesa. Ese logro elimina algunas vías de fallo, especialmente la administración extranjera directa y el cierre remoto específico para un cliente por parte del proveedor de tecnología. No elimina la física, el envejecimiento del software, el error humano o la concentración de clientes.
Evidencia que un comprador debe obtener antes de comprometer una carga de trabajo crítica
La primera evidencia debe describir la ubicación. S3NS puede confirmar, bajo la confidencialidad adecuada, que los servicios seleccionados utilizan los tres centros de datos, qué componentes siguen siendo zonales, cuáles son regionales y qué dependencias del plano de control cruzan las zonas. A continuación, el cliente puede mapear cada componente de cómputo, almacenamiento, identidad, clave, registro y despliegue a un dominio de fallo.
La segunda evidencia debe describir la capacidad de supervivencia. Para cada máquina crítica y servicio gestionado, el cliente necesita saber si hay capacidad equivalente reservada o es probable que esté disponible después de perder una zona. Deben incluirse procesadores especializados, formas de gran memoria, rendimiento de almacenamiento y direcciones públicas. Un ejercicio exitoso en el que las cargas de trabajo se reinician en otra zona es más valioso que un adjetivo de disponibilidad.
La tercera evidencia debe describir la diversidad física y de red sin exponer detalles sensibles públicamente. El riesgo independiente de las instalaciones y los servicios públicos, las entradas separadas, las rutas entre zonas, la propiedad de los operadores, la terminación de la interconexión y el ancho de banda de conmutación por error pueden validarse en un entorno de aseguramiento controlado. La respuesta debe identificar las dependencias compartidas, no simplemente contar los contratos.
La cuarta evidencia debe describir la reparación y la escalada. El cliente debe saber quién responde a cada hora, cuándo se involucra el personal de sitio de S3NS, qué reparaciones dependen de los proveedores de instalaciones o hardware, qué piezas se mantienen localmente y cómo un problema llega a Google sin exponer los datos del cliente. Las comunicaciones de incidentes graves deben tener una ruta fuera de banda.
La quinta evidencia debe ser un ejercicio de recuperación regional. Dado que hay una sola región de PREMI3NS, el cliente debe restaurar un servicio representativo fuera de ella, incluidos los datos, las claves, la identidad, la configuración y la entrada de red. El resultado medido debe compararse con el objetivo de recuperación del negocio. Cualquier paso que asuma que la consola de origen sigue estando disponible debe probarse de nuevo sin esa suposición.
Finalmente, el contrato debe alinearse con el resultado técnico. El alcance de la calificación, los niveles de servicio, el mantenimiento, la asistencia en incidentes, la ubicación de los datos, los subcontratistas, la continuidad del suministro de software, la portabilidad, la eliminación y el soporte de terminación deben describir el mismo servicio que los ingenieros probaron. Un contrato no puede crear capacidad, pero puede hacer que la responsabilidad y la evidencia estén disponibles antes de un fallo.
La calificación de evidencia es Media
S3NS ha cruzado el umbral de proyecto plausible a operador evidenciado. PREMI3NS está disponible con carácter general, tiene un proveedor legal designado, emplea a un equipo francés sustancial, opera una región independiente documentada, expone un amplio catálogo de servicios gestionados, tiene programas públicos de clientes y posee una calificación SecNumCloud 3.2 vigente para IaaS, PaaS y CaaS. Estas son señales más sólidas que un mapa de marketing, un registro de empresa inactivo o una etiqueta de nube no verificada.
La rebaja respecto a Fuerte refleja lo que sigue sin estar disponible públicamente. No se nombran los tres operadores de centros de datos ni las ubicaciones exactas. No se describe la diversidad de servicios públicos, operadores, red troncal e interconexiones. No hay recuentos públicos de flota, límites de evacuación de zona, calendarios de repuestos ni condiciones completas de respuesta de soporte al cliente. Lo más importante es que PREMI3NS tiene una sola región. Sus tres zonas mejoran la disponibilidad, pero no proporcionan recuperación dentro de la plataforma ante la pérdida de la región.
Por lo tanto, la conclusión justa no es ni "el control francés lo resuelve todo" ni "la tecnología de Google hace que la soberanía no tenga sentido". ANSSI ha establecido que Thales Cloud Sécurisé controla el entorno calificado y lo protege del acceso legal no europeo en las condiciones establecidas. La plataforma sigue dependiendo de la tecnología de Google, la infraestructura de centros de datos franceses, la electricidad, la fibra, el suministro de hardware y el personal de S3NS. Estas dependencias pueden gestionarse porque son identificables; no pueden gestionarse fingiendo que desaparecieron.
Para un comprador, la característica más valiosa de S3NS puede ser la claridad de su límite. El servicio es una región de nube francesa y autónoma con tres zonas físicas, operada por una empresa francesa controlada por Thales que utiliza la tecnología de Google Cloud bajo un modelo de control calificado. Construya a través de las zonas. Demuestre la capacidad en los sitios supervivientes. Obtenga evidencia confidencial de la diversidad física y de rutas. Mantenga un entorno de recuperación probado más allá de la región.
Entonces, la promesa de soberanía se convierte en una capacidad operativa en lugar de una insignia adherida a los racks de otra persona.