1. Aislamiento de red: Omitir completamente el internet público para el tráfico de inferencia no es negociable para cargas de trabajo sensibles. Esto previene ataques comunes basados en la red y la interceptación de datos.
2. Seguridad perimetral (VPC-SC): Establecer barreras contra la exfiltración de datos y el acceso entre proyectos no autorizado. Esto actúa como un cortafuegos lógico.
3. Protección de datos: Asegurarse de que los modelos y los datos se cifren en reposo y en tránsito utilizando claves administradas por el cliente. Esto me da control directo sobre mi material criptográfico.
4. Acceso con privilegios mínimos: Implementar roles de IAM granulares, separando las preocupaciones del despliegue del modelo de la invocación del modelo. Esto minimiza el radio de acción de cualquier credencial comprometida.
5. Gobernanza del modelo: Implementar prácticas como la firma del modelo (por ejemplo, usando Sigstore/Cosign), el escaneo de vulnerabilidades de las dependencias del modelo y el registro de auditoría completo para todos los eventos del ciclo de vida del modelo. Esto genera confianza y trazabilidad en la cadena de suministro de IA.
6. Cumplimiento de la soberanía: Alinearse con los marcos regulatorios aprovechando ofertas en la nube y asociaciones específicas, asegurando que el control legal y operativo resida dentro de jurisdicciones conformes.

Así es como estos componentes encajan para una implementación de Vertex AI altamente segura:

Cuando se trata de aislamiento de red, normalmente elijo Private Service Connect (PSC) en lugar de VPC Peering para conectarme a servicios gestionados como Vertex AI. Si bien VPC Peering funciona, PSC ofrece una separación más limpia. Con PSC, los servicios de Vertex AI se presentan como puntos de conexión directamente dentro de mi VPC, consumiendo una dirección IP interna. Esto elimina la necesidad de enrutamiento transitivo o la gestión de redes emparejadas, lo que simplifica mi arquitectura de red y reduce la superficie de ataque. Es una conexión de red dedicada e interna, que omite completamente la internet pública.

VPC Service Controls (VPC-SC) es mi muro digital de Fort Knox. Me permite definir perímetros de seguridad alrededor de mis proyectos de GCP y los servicios dentro de ellos, como Vertex AI y Cloud Storage. Cualquier intento de mover datos o acceder a recursos desde fuera de este perímetro se bloquea, independientemente de los permisos de IAM. Esta es una línea de defensa crítica contra la exfiltración de datos, asegurando que incluso si un atacante compromete una cuenta de servicio, no pueda extraer datos fuera de mi perímetro definido. Crea de manera efectiva una separación lógica basada en políticas para mis servicios sensibles.

Para los datos en reposo y en tránsito, las claves de cifrado gestionadas por el cliente (CMEK) son primordiales. Si bien Google cifra los datos por defecto, CMEK me da a mí el control criptográfico sobre las claves que protegen mis modelos en el Registro de modelos de Vertex AI y sus artefactos asociados en Cloud Storage. Este es un requisito común en las industrias reguladas. Para los datos en tránsito, los puntos de conexión privados de Vertex AI utilizan inherentemente TLS (Transport Layer Security), lo que garantiza que toda la comunicación entre mi VPC y el servicio de Vertex AI esté cifrada y sea segura.

Finalmente, la gestión de identidades y accesos (IAM) debe ser quirúrgica. Siempre abogo por cuentas de servicio separadas para acciones distintas. La identidad que implementa un modelo debe ser diferente de la cuenta de servicio que invoca el punto de conexión para la inferencia. Esto se adhiere al principio de privilegio mínimo, minimizando el radio de explosión de cualquier credencial comprometida. Por ejemplo, una cuenta de servicio model-deployer podría tener aiplatform.admin en los modelos, mientras que una cuenta de servicio inference-invoker solo tendría aiplatform.user en puntos de conexión específicos.

En Europa, la conversación en torno a la soberanía de los datos y la confianza digital se está intensificando. El concepto de "cloud de confiance" (nube de confianza) está ganando terreno, particularmente en Francia con su certificación SecNumCloud. Pero para comprender realmente lo que estos requisitos significan para las cargas de trabajo de IA en GCP, vale la pena ir más allá de las menciones y examinar los mecanismos por los cuales los controles de seguridad estándar de la nube —incluso los reforzados como los cubiertos en esta guía— no son suficientes para las organizaciones que operan bajo mandatos del sector público francés o estrictos requisitos de soberanía de la UE.

El problema raíz: la ley extraterritorial

Antes de hablar de S3NS, necesitamos entender por qué existe. La US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) significa que una empresa estadounidense, incluida Google, puede ser obligada a entregar datos que controla, incluso si esos datos están físicamente almacenados en Europa. Los controles de seguridad estándar de la nube (VPC Service Controls, CMEK, Private Service Connect) le protegen de amenazas externas y configuraciones erróneas, pero no cambian la realidad jurisdiccional fundamental: Google es una entidad estadounidense y su personal operativo puede, en teoría, ser obligado a actuar bajo la ley estadounidense. Esto es lo que abordan directamente SecNumCloud y S3NS.

¿Qué es SecNumCloud?

SecNumCloud es un marco de calificación publicado por ANSSI (Agence nationale de la sécurité des systèmes d'information), la agencia nacional francesa de ciberseguridad. La versión 3.2 —la versión actual y operativamente significativa— comprende 276 requisitos en 15 dominios de seguridad: seguridad operativa, criptología, control de acceso, seguridad de red, continuidad del negocio, gestión de incidentes y, fundamentalmente, protección contra leyes extraterritoriales. Este último dominio es lo que distingue a SecNumCloud de otras certificaciones de seguridad europeas como ISO 27001 o BSI C5. No es puramente un estándar de ciberseguridad; es simultáneamente un marco de control jurisdiccional. Un proveedor solo puede recibir la calificación SecNumCloud si puede demostrar que los gobiernos extranjeros no tienen ningún mecanismo legal o técnico para obligar el acceso a los datos del cliente.

S3NS: Estructura y diseño corporativo

S3NS (pronunciado sens, francés para "sentido") es una empresa conjunta estructurada para ser legalmente inmune a la presión extraterritorial de EE. UU. desde su inicio. Datos clave:

• Participación mayoritaria: Thales tiene la participación mayoritaria; Google Cloud tiene aproximadamente un 20 %.
• Jurisdicción legal: S3NS es una société par actions simplifiée (SAS) francesa, legalmente obligada exclusivamente bajo la ley europea.
• Consecuencia: Cualquier solicitud de datos del gobierno de EE. UU. dirigida a S3NS puede ser —y sería— rechazada; no existe ningún mecanismo legal a través del cual Google pueda obligar unilateralmente a S3NS a actuar.

La estructura corporativa es una ingeniería intencional de soberanía: Google aporta la tecnología, Thales y S3NS aportan el marco legal europeo y el control operativo.

Dos niveles: CRYPT3NS vs. PREMI3NS

S3NS ofrece dos niveles de servicio distintos, y confundirlos es un error común:

Para la mayoría de las organizaciones privadas de la UE, CRYPT3NS proporciona una protección significativa a través de controles de residencia de datos y jurisdicción legal. Para las organizaciones sujetas a estrictas normas de contratación pública francesas, cadenas de suministro de defensa o sectores que requieren explícitamente la calificación SecNumCloud, solo PREMI3NS cumple con los requisitos.

Cómo PREMI3NS logra el aislamiento técnico

Esta es la pregunta central: ¿cómo pueden los servicios de GCP ejecutarse en un centro de datos sobre el cual Google no tiene control?

La respuesta es Google Cloud Dedicated, una arquitectura donde Google licencia su pila tecnológica (software de computación, almacenamiento y redes) a S3NS, que luego la implementa y opera completamente en su propia infraestructura física. Varios mecanismos de control deliberados hacen esto posible:

1. Infraestructura físicamente aislada: PREMI3NS se ejecuta en su propio hardware de computación, almacenamiento y redes en centros de datos franceses. Estos sistemas están completamente separados de la nube pública global de Google; no hay un tejido compartido ni un plano de control común accesible para los empleados de Google.

2. Acceso cero de Google: El personal de Google no tiene acceso físico o lógico al entorno PREMI3NS. Las operaciones, la administración y el soporte son realizados exclusivamente por empleados de S3NS ubicados dentro de la UE. Las escaladas que normalmente llegarían a la ingeniería de Google son manejadas internamente por S3NS.

3. Modelo de cuarentena de actualizaciones: Cuando Google lanza una actualización de software —parches de kernel, actualizaciones de servicio, nuevas características—, S3NS la intercepta en un entorno de cuarentena. Los ingenieros de S3NS realizan ingeniería inversa automatizada y análisis de seguridad en los binarios antes de decidir si desplegarlos en producción. S3NS no ejecuta pasivamente el código de Google; es un guardián activo de cada cambio de software que llega a su infraestructura.

4. Control criptográfico soberano: S3NS gestiona las raíces criptográficas de confianza para el entorno PREMI3NS. A diferencia de CMEK en GCP estándar, donde usted gestiona las claves pero Google sigue operando la infraestructura, en PREMI3NS toda la jerarquía de gestión de claves se encuentra bajo el control de S3NS y del cliente, no de Google.

5. Modelo SOC dual: S3NS opera su propio Centro de Operaciones de Seguridad en coordinación con el SOC P10 certificado por ANSSI de Thales, proporcionando una doble monitorización de comportamientos anómalos, incluido cualquier intento de introducir una ruta de acceso accesible a Google.

Catálogo de servicios actual y la hoja de ruta de Vertex AI

A partir de la calificación de diciembre de 2025, PREMI3NS cubre la infraestructura principal para la mayoría de las cargas de trabajo reguladas: Compute Engine, GPU de Cloud (NVIDIA H100s), Cloud Storage, redes (DNS, VPN, balanceo de carga, Cloud Armor, Interconnect), BigQuery Enterprise, Pub/Sub, GKE Autopilot, Cloud SQL Enterprise Plus y herramientas de operaciones (Monitoring, Logging). Una segunda ola —Cloud Run, Cloud Build, Cloud Spanner, Cloud Bigtable, Secret Manager, VM confidenciales y Admin Access Transparency— está pendiente de calificación para el primer semestre de 2026.

Para Vertex AI específicamente, las bases principales (Model Garden para modelos de peso abierto, Model Registry, Workbench e inferencia en línea) están en la hoja de ruta para el segundo semestre de 2026. Gemini no estará en el Model Garden inicial; solo se incluyen inicialmente modelos de código abierto y de peso abierto, lo cual es una consideración material para el diseño de inferencia de IA soberana hoy. Si necesita inferencia calificada por SecNumCloud en este momento, el camino práctico es implementar sus propios modelos en GKE Autopilot con GPU H100 en PREMI3NS. Vertex AI administrado en PREMI3NS es inminente, aún no se ha entregado.

Cuándo usar S3NS frente al endurecimiento estándar de GCP

Los controles cubiertos en el resto de esta guía (PSC, VPC-SC, CMEK) son muy efectivos para la gran mayoría de las cargas de trabajo reguladas de la UE. La siguiente heurística ayuda a decidir qué nivel es apropiado:

• GCP estándar reforzado (esta guía): suficiente para GDPR, NIS2, ISO 27001, marcos bancarios/de seguros y cualquier organización donde el aislamiento operativo de la ley estadounidense no sea un requisito de adquisición explícito.
• CRYPT3NS: apropiado cuando se necesitan garantías de jurisdicción legal francesa y residencia de datos, pero no se exige un aislamiento completo de la infraestructura.
• PREMI3NS: obligatorio cuando se requiere la calificación SecNumCloud —OIV (Operadores de Importancia Vital) franceses, cadena de suministro de defensa, datos gubernamentales sensibles o cualquier especificación de adquisición que haga referencia explícita a SecNumCloud.

La adjudicación del contrato de la nube soberana de la UE por 180 millones de euros, que involucra a S3NS, y la propia adopción por parte de Thales de SAP RISE en PREMI3NS, señalan que este modelo ha pasado de la fase piloto a la producción a gran escala.

Primero, establezco una conexión privada a Vertex AI. Esto implica crear un punto de conexión de Private Service Connect en mi VPC que se conecta a la red del productor de servicios de Vertex AI. Tenga en cuenta que Vertex AI aprovisiona internamente su propio adjunto de servicio; solo necesito configurar el lado del consumidor en mi proyecto.

# main.tf
# Define variables for your project and region
variable "gcp_project_id" {
  description = "The ID of your GCP project."
  type        = string
}

variable "gcp_region" {
  description = "The GCP region for resources (e.g., europe-west1)"
  type        = string
  default     = "europe-west1" # Always prefer European regions
}

variable "vpc_network_name" {
  description = "The name of your existing VPC network."
  type        = string
  default     = "vertex-ai-inference-vpc" # Example VPC name
}

# Configure the GCP provider
provider "google" {
  project = var.gcp_project_id
  region  = var.gcp_region
}

# Create a Private Service Connect endpoint for Vertex AI
# This service attachment name is specific to Vertex AI Prediction
# and is a Google-managed producer endpoint.
resource "google_compute_network_attachment" "vertex_ai_psc_endpoint" {
  name        = "vertex-ai-psc-endpoint"
  project     = var.gcp_project_id
  region      = var.gcp_region
  description = "PSC endpoint for Vertex AI Prediction service."
  network     = "projects/${var.gcp_project_id}/global/networks/${var.vpc_network_name}"

  # The service_attachment_names array must reference the Google-managed producer attachment.
  # For Vertex AI Prediction, the format is 'projects/REGION-aiplatform/regions/REGION/serviceAttachments/aiplatform-producer-REGION'
  # Replace REGION with the specific region you are deploying to (e.g., europe-west1).
  service_attachment_names = ["projects/${var.gcp_region}-aiplatform/regions/${var.gcp_region}/serviceAttachments/aiplatform-producer-${var.gcp_region}"]
}

output "psc_endpoint_link" {
  description = "The self_link of the Private Service Connect network attachment."
  value       = google_compute_network_attachment.vertex_ai_psc_endpoint.self_link
}

# Note: For managed services like Vertex AI, you typically interact via DNS names
# that resolve to the private IP behind the scenes. This PSC endpoint enables that private resolution.

Esta configuración de Terraform configura el lado del consumidor de PSC. La clave es identificar correctamente los service_attachment_names para la Predicción de Vertex AI en la región elegida. Una vez implementado, todo el tráfico de su vertex-ai-inference-vpc a este punto de conexión se enrutará de forma privada a Vertex AI. Si bien el resultado psc_endpoint_link proporciona el enlace del recurso, para los servicios administrados como Vertex AI, normalmente interactúa a través de nombres DNS que se resuelven en esta IP privada en segundo plano. Consulte la documentación oficial de Private Service Connect para obtener los nombres de adjuntos de servicio más actualizados.

A continuación, defino un perímetro de seguridad alrededor de mis proyectos y servicios críticos. Este ejemplo asume que tiene una organización definida en GCP, lo cual es un prerrequisito para VPC-SC.

# vpc_sc.tf
resource "google_access_context_manager_service_perimeter" "vertex_ai_perimeter" {
  parent = "organizations/YOUR_ORGANIZATION_ID" # IMPORTANT: Replace with your actual organization ID
  name   = "accessPolicies/YOUR_ACCESS_POLICY_ID/servicePerimeters/vertex_ai_sec_perimeter" # IMPORTANT: Replace with your actual Access Policy ID
  title  = "vertex-ai-sec-perimeter"

  perimeter_type = "REGULAR"

  status {
    restricted_services = [
      "aiplatform.googleapis.com",
      "storage.googleapis.com" # Critical for models and artifacts in Cloud Storage
    ]

    # If you have specific access levels defined (e.g., trusted IP ranges or device policies),
    # you would list them here. For this example, we assume basic project inclusion.
    # For creating an access policy and level, refer to Google Cloud's Access Context Manager docs.
    # access_levels = [
    #   "accessPolicies/YOUR_ACCESS_POLICY_ID/accessLevels/trusted_networks_and_devices" # Example access level
    # ]

    resources = [
      "projects/${var.gcp_project_id}" # Your project where Vertex AI is deployed
    ]
  }

  description = "VPC-SC perimeter for Vertex AI and associated storage."
}

Este bloque de Terraform crea un perímetro de VPC-SC. Incluyo aiplatform.googleapis.com y storage.googleapis.com en restricted_services porque mis modelos y conjuntos de datos a menudo residen en Cloud Storage. El campo resources especifica qué proyectos están protegidos por este perímetro. Recuerde, las políticas de VPC-SC se evalúan después de IAM, por lo que incluso si una identidad tiene permisos de storage.admin, si está fuera del perímetro o viola un nivel de acceso, su solicitud será denegada. Esto proporciona una capa robusta de prevención de exfiltración de datos.

Nota: La configuración de access_levels y access_policies requiere una planificación cuidadosa a nivel de organización. Para obtener una guía detallada, consulte la documentación de VPC Service Controls.

Tomar el control de sus claves de cifrado es un paso vital para el cumplimiento normativo. Crearé un anillo de claves de Cloud KMS y una clave, y luego otorgaré los permisos necesarios para que Vertex AI la use.

# Step 3a: Create a KMS Key Ring and Key
# Key rings organize keys; keys perform encryption/decryption.
KMS_KEYRING_NAME="vertex-ai-model-keyring"
KMS_KEY_NAME="vertex-ai-model-key"
KMS_LOCATION="europe-west1" # Match your Vertex AI region for optimal latency
PROJECT_ID="my-gcp-project-id" # Replace with your actual project ID

gcloud kms keyrings create "${KMS_KEYRING_NAME}" \n       --location="${KMS_LOCATION}" \n       --project="${PROJECT_ID}"

gcloud kms keys create "${KMS_KEY_NAME}" \n       --keyring="${KMS_KEYRING_NAME}" \n       --location="${KMS_LOCATION}" \n       --purpose="encryption" \n       --project="${PROJECT_ID}"

# Step 3b: Grant Vertex AI Service Agent permissions to use the KMS Key
# The Vertex AI Service Agent is specific to your project and region.
# Format: service-<PROJECT_NUMBER>@gcp-sa-aiplatform.iam.gserviceaccount.com
# Get your project number:
PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
VERTEX_AI_SERVICE_AGENT="service-${PROJECT_NUMBER}@gcp-sa-aiplatform.iam.gserviceaccount.com"

KMS_KEY_RESOURCE="projects/${PROJECT_ID}/locations/${KMS_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}"

gcloud kms keys add-iam-policy-binding "${KMS_KEY_NAME}" \n       --location="${KMS_LOCATION}" \n       --keyring="${KMS_KEYRING_NAME}" \n       --member="serviceAccount:${VERTEX_AI_SERVICE_AGENT}" \n       --role="roles/cloudkms.cryptoKeyEncrypterDecrypter" \n       --project="${PROJECT_ID}"

echo "KMS Key Resource Name: ${KMS_KEY_RESOURCE}"

Salida esperada (ejemplo para la creación de claves):

Created keyring [vertex-ai-model-keyring].
Created key [vertex-ai-model-key].
Updated IAM policy for key [vertex-ai-model-key].
KMS Key Resource Name: projects/my-gcp-project-id/locations/europe-west1/keyRings/vertex-ai-model-keyring/cryptoKeys/vertex-ai-model-key

Ahora, cuando subo o registro un modelo con Vertex AI, especifico esta KMS_KEY_RESOURCE para garantizar que mis artefactos del modelo se cifren con mi CMEK. Esto se realiza típicamente durante la operación Model.upload() en el SDK de Vertex AI o a través de la API REST:

# Python 3.13+ example for uploading a model with CMEK
from google.cloud import aiplatform

PROJECT_ID = "my-gcp-project-id" # Replace with your actual project ID
REGION = "europe-west1"
MODEL_DISPLAY_NAME = "my-secure-model"
MODEL_ARTIFACT_URI = "gs://my-secure-model-bucket/path/to/model/artifacts/" # Replace with your GCS bucket for model artifacts
SERVING_CONTAINER_IMAGE_URI = "europe-west1-docker.pkg.dev/cloud-aiplatform/prediction/tf2-cpu.2-11:latest"
KMS_KEY_RESOURCE = f"projects/{PROJECT_ID}/locations/{REGION}/keyRings/{KMS_KEYRING_NAME}/cryptoKeys/{KMS_KEY_NAME}"

# Initialize the Vertex AI SDK
aiplatform.init(project=PROJECT_ID, location=REGION)

# Upload the model with CMEK
model = aiplatform.Model.upload(
    display_name=MODEL_DISPLAY_NAME,
    artifact_uri=MODEL_ARTIFACT_URI,
    serving_container_image_uri=SERVING_CONTAINER_IMAGE_URI,
    encryption_spec_key_name=KMS_KEY_RESOURCE,
    sync=True
)

print(f"Model uploaded and encrypted with CMEK: {model.resource_name}")

Esto garantiza que su modelo, cuando se almacena en el registro y en los buckets de Cloud Storage asociados, esté protegido por sus claves criptográficas, lo que cumple un requisito crítico de soberanía.

La implementación del privilegio mínimo es crucial. Separo los permisos para la implementación del modelo de los de la invocación del modelo. Así es como creo una cuenta de servicio dedicada para la inferencia y le otorgo solo los permisos necesarios.

# Step 4a: Create a dedicated service account for inference
PROJECT_ID="my-gcp-project-id" # Replace with your actual project ID
INFERENCE_SA_NAME="vertex-inference-sa"
INFERENCE_SA_DESCRIPTION="Service account for invoking Vertex AI endpoints."

gcloud iam service-accounts create "${INFERENCE_SA_NAME}" \n       --display-name="${INFERENCE_SA_DESCRIPTION}" \n       --project="${PROJECT_ID}"

INFERENCE_SA_EMAIL="${INFERENCE_SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"

# Step 4b: Grant necessary roles for endpoint invocation
# aiplatform.user allows invoking predictions on endpoints.
# aiplatform.endpointViewer might also be needed to view endpoint details.

gcloud projects add-iam-policy-binding "${PROJECT_ID}" \n       --member="serviceAccount:${INFERENCE_SA_EMAIL}" \n       --role="roles/aiplatform.user" \n       --project="${PROJECT_ID}"

gcloud projects add-iam-policy-binding "${PROJECT_ID}" \n       --member="serviceAccount:${INFERENCE_SA_EMAIL}" \n       --role="roles/aiplatform.endpointViewer" \n       --project="${PROJECT_ID}"

echo "Inference Service Account: ${INFERENCE_SA_EMAIL}"

Salida esperada (ejemplo):

Created service account [vertex-inference-sa].
Updated policy for project [my-gcp-project-id].
Updated policy for project [my-gcp-project-id].
Inference Service Account: vertex-inference-sa@my-gcp-project-id.iam.gserviceaccount.com

Cuando su aplicación cliente u otros servicios necesiten llamar al punto de conexión de Vertex AI, deben suplantar esta cuenta de servicio vertex-inference-sa o usar sus credenciales. Esto minimiza el riesgo: si esta cuenta de servicio se ve comprometida, solo puede invocar predicciones y no puede, por ejemplo, eliminar modelos o modificar su configuración de Vertex AI.

Finalmente, implemento el modelo cifrado con CMEK en un punto de conexión que aprovecha nuestra configuración de red privada. Definiré un recurso de punto de conexión y desplegaré el modelo que subimos anteriormente.

# Python 3.13+ example for deploying to a private endpoint
from google.cloud import aiplatform

PROJECT_ID = "my-gcp-project-id" # Replace with your actual project ID
REGION = "europe-west1"
MODEL_RESOURCE_NAME = model.resource_name # From previous step's model upload
ENDPOINT_DISPLAY_NAME = "my-secure-inference-endpoint"

# Initialize the Vertex AI SDK
aiplatform.init(project=PROJECT_ID, location=REGION)

# Define the endpoint configuration
endpoint = aiplatform.Endpoint.create(
    display_name=ENDPOINT_DISPLAY_NAME,
    project=PROJECT_ID,
    location=REGION,
    # network and enable_private_service_connect are key for private endpoint
    # The network must be in the same region as the endpoint. This refers to your VPC.
    network=f"projects/{PROJECT_ID}/global/networks/vertex-ai-inference-vpc", # Use your defined VPC network name
    enable_private_service_connect=True,
    sync=True
)

# Deploy the model to the endpoint
# You might specify machine type and other scaling settings here.
# This example assumes a simple deployment.
endpoint.deploy(
    model=model,
    deployed_model_display_name=f"{MODEL_DISPLAY_NAME}-deployed",
    machine_type="n1-standard-4", # Example machine type
    min_replica_count=1,
    max_replica_count=2,
    sync=True
)

print(f"Model {MODEL_DISPLAY_NAME} deployed to private endpoint: {endpoint.resource_name}")

Esta implementación garantiza que su modelo se aloje en un punto de conexión accesible solo a través de su enlace de Private Service Connect configurado, operando dentro del perímetro de VPC Service Controls y utilizando sus claves de cifrado administradas por el cliente.

Repositorio de ejemplo completo: Puede encontrar más ejemplos oficiales de patrones seguros de Vertex AI en github.com/GoogleCloudPlatform/vertex-ai-samples/tree/main/community-content/vertex_security_examples.

Ejemplos de código adicionales: Para patrones de implementación avanzados e integración CI/CD para Vertex AI, un repositorio con mis implementaciones más complejas generalmente se encuentra en mi flujo de trabajo privado.

Para verificar que su punto de conexión es privado y seguro, debe intentar invocarlo desde dentro de su red VPC, utilizando la cuenta de servicio con permisos restringidos.

# Python 3.13+ example for invoking the private endpoint
from google.cloud import aiplatform
from google.oauth2 import service_account

PROJECT_ID = "my-gcp-project-id" # Replace with your actual project ID
REGION = "europe-west1"
# Replace with your endpoint's full resource name (e.g., projects/PROJECT_NUMBER/locations/europe-west1/endpoints/ENDPOINT_ID)
ENDPOINT_RESOURCE_NAME = "projects/123456789012/locations/europe-west1/endpoints/1234567890"
INFERENCE_SA_KEY_PATH = "/path/to/your/vertex-inference-sa-key.json" # Path to the downloaded service account key file

# Initialize the AI Platform client with the service account credentials
credentials = service_account.Credentials.from_service_account_file(INFERENCE_SA_KEY_PATH)

aiplatform.init(project=PROJECT_ID, location=REGION, credentials=credentials)

# Prepare sample data for prediction (replace with actual model input format)
# This is illustrative pseudocode for data; adapt for your model's expected input.
instances = [
    {"feature_1": 1.0, "feature_2": "value"},
    {"feature_1": 2.5, "feature_2": "another_value"}
]

# Get the endpoint instance by its resource name
endpoint = aiplatform.Endpoint(ENDPOINT_RESOURCE_NAME)

try:
    prediction = endpoint.predict(instances=instances)
    print("Prediction successful:")
    print(prediction.predictions)
except Exception as e:
    print(f"Prediction failed: {e}")
    print("Verify network, IAM, and VPC-SC configurations.")

Salida esperada:

Prediction successful:
[model output data]

Si intenta llamar a este punto de conexión desde fuera de su VPC (por ejemplo, desde su máquina local sin VPN/Cloud Interconnect a su VPC), o sin usar las credenciales de vertex-inference-sa, debería esperar un error de conexión o un mensaje de permiso denegado, lo que confirma que sus controles de seguridad están activos.

1. Error: Violación de los controles de servicio de VPC

La solicitud está prohibida por la política de la organización.

**Solución:** Esto generalmente significa que una solicitud (por ejemplo, intentar acceder a un bucket fuera del perímetro o desde una IP no conforme) está bloqueada por VPC-SC. Vuelva a verificar su configuración de `google_access_context_manager_service_perimeter`. Asegúrese de que el rango de IP o el nivel de acceso de su cliente estén definidos correctamente dentro de la política de acceso si la solicitud es legítima. Además, verifique que todos los servicios de los que depende su operación (como Cloud Storage para artefactos de modelo) estén incluidos en `restricted_services` y que el proyecto esté listado en `resources` dentro del perímetro. Para obtener detalles específicos sobre los niveles de acceso, consulte la [documentación de Google Cloud Access Context Manager](https://cloud.google.com/access-context-manager/docs/overview).

1. Error: Permiso IAM denegado

403 Permiso denegado en el recurso projects/PROJECT_NUMBER/locations/REGION/endpoints/ENDPOINT_ID

**Solución:** La cuenta de servicio o el usuario que realiza la solicitud carece del rol `aiplatform.user` necesario (o `aiplatform.endpointViewer` si solo intenta ver los detalles del punto de conexión) en el punto de conexión o proyecto de Vertex AI. Verifique las vinculaciones de políticas de IAM para su cuenta de servicio de inferencia utilizando `gcloud iam service-accounts get-iam-policy INFERENCE_SA_EMAIL` y `gcloud projects get-iam-policy my-gcp-project-id`. Asegúrese de que los roles correctos se otorguen en el ámbito apropiado.

1. Error: Problema de conectividad de Private Service Connect

No se pudo conectar al punto de conexión. Compruebe la configuración de red.

**Solución:** Esto implica un problema con la ruta de red privada. Verifique que su `google_compute_network_attachment` esté correctamente aprovisionado y que su estado sea `ACCEPTED`. Verifique las reglas de firewall en su VPC para asegurarse de que se permita el tráfico desde su cliente al rango de IP del punto de conexión PSC. Además, confirme que la resolución DNS para el punto de conexión de Vertex AI se resuelva en una IP interna dentro de su VPC, no en una pública. Si utiliza `gcloud`, asegúrese de que su cliente se esté ejecutando desde una VM dentro de la misma VPC o esté conectado a través de VPN/Interconnect.