Semana 8 · Módulo 8 de 12

Cumplimiento normativo e IA en Google Cloud

En la primera parte aprenderás a traducir normas (RGPD, HIPAA, PCI DSS, SOC 2…) y requisitos de soberanía en controles concretos de Google Cloud. En la segunda, el panorama de IA que exige la guía actual del examen, con Gemini Enterprise Agent Platform (antes Vertex AI), Gemini Enterprise, RAG y la seguridad de la IA, muy presentes en los casos de estudio.

Reparto de la semana

Por qué importa

El apartado 3.2 pide diseñar para cumplimiento: privacidad de historias clínicas, privacidad infantil, protección de datos, soberanía, datos de tarjetas, PII, certificaciones como SOC 2 y auditorías. El examen no te pide ser abogado: te pide reconocer qué control técnico resuelve cada requisito y saber qué parte es responsabilidad de Google (sus certificaciones) y qué parte es tuya (tu configuración).

La IA, por su parte, aparece en los apartados 1.3, 2.4, 2.5 y 3.1, y varios casos de estudio (Cymbal Retail, Altostrat Media, EHR Healthcare, KnightMotives) la incluyen como requisito de negocio. El examen de renovación está centrado casi por completo en un caso de IA generativa. Aquí aprenderás el mapa de productos con sus nombres actuales, que cambiaron mucho en 2025 y 2026.

Parte A: cumplimiento normativo

Esta primera parte cubre el apartado 3.2: qué exige cada norma y con qué controles de Google Cloud lo demuestras.

Responsabilidad en el cumplimiento

Google Cloud obtiene certificaciones y auditorías de terceros sobre su infraestructura (ISO/IEC 27001, 27017, 27018, SOC 1/2/3, PCI DSS como proveedor de servicios, ENS categoría alta en España, entre otras). Eso no certifica tu aplicación: te da una base auditada sobre la que construir, y tú debes configurar tu parte (IAM, cifrado, logs, ubicación, retención). Los informes (SOC 2, certificados ISO, atestación PCI) se descargan desde Compliance Reports Manager y los contratos clave son el Cloud Data Processing Addendum (encargo del tratamiento) y, para salud en EE. UU., el Business Associate Agreement (BAA).

Marcos que debes reconocer

Datos personales, seudonimización y anonimización

Para el RGPD, un dato seudonimizado (p. ej. el DNI sustituido por un token reversible con una llave) sigue siendo dato personal, porque puede reidentificarse; reduce el riesgo, pero no saca el dato del ámbito del reglamento. Un dato realmente anonimizado (irreversible y sin posibilidad razonable de reidentificación) ya no es dato personal. Esta distinción aparece al elegir técnicas de Sensitive Data Protection.

Residencia y soberanía del dato

Tres conceptos que conviene separar:

• Residencia del dato: dónde se almacena y procesa físicamente (p. ej. «solo en la UE»).
• Control de acceso del proveedor: quién de Google puede acceder, cuándo y con qué justificación.
• Soberanía: control jurídico y operativo (quién opera la infraestructura, bajo qué jurisdicción, quién tiene las llaves, si puede funcionar desconectado).

Controles de residencia y acceso

• Política de organización gcp.resourceLocations: limita las regiones donde se pueden crear recursos (p. ej. in:eu-locations o solo europe-southwest1).
• CMEK y Cloud EKM: si la llave está fuera de Google (EKM), Google no puede descifrar sin tu gestor externo. Con Key Access Justifications cada petición de uso de la llave llega con un motivo que tu gestor puede aprobar o rechazar.
• Access Transparency: registros casi en tiempo real de las acciones que el personal de Google realiza sobre tu contenido, con el motivo (p. ej. un caso de soporte). Complementa a Cloud Audit Logs, que registran lo que hace tu personal.
• Access Approval: va un paso más allá y exige tu aprobación explícita antes de que el personal de Google acceda a tus datos (con excepciones documentadas, como obligaciones legales o determinadas incidencias).

flowchart LR
  Q["¿Quién accede?"] --> T["Tu personal"]
  Q --> G["Personal de Google"]
  T --> AL["Cloud Audit Logs"]
  G --> AT["Access Transparency: ver"]
  G --> AA["Access Approval: aprobar antes"]
  G --> KAJ["Key Access Justifications + Cloud EKM: la llave decide"]

Assured Workloads

Assured Workloads crea una carpeta con un control package que aplica automáticamente las restricciones de un régimen: ubicaciones permitidas, servicios permitidos, requisitos de personal de soporte, cifrado y monitorización de infracciones. Los paquetes se han renombrado recientemente; hoy hay, por ejemplo, EU Data Boundary, EU Data Boundary and Support, EU Data Boundary with Access Justifications, US Data Boundary for Healthcare and Life Sciences o paquetes regulatorios de EE. UU. (FedRAMP/IL, CJIS, ITAR). Si el enunciado dice «imponer automáticamente los controles de residencia y soporte de la UE a un conjunto de proyectos», es Assured Workloads.

Ofertas soberanas de Google en Europa

La página oficial de Sovereign Cloud from Google agrupa hoy tres niveles:

Sensitive Data Protection

Sensitive Data Protection (SDP), antes conocido como Cloud DLP (la API sigue siendo dlp.googleapis.com), descubre, clasifica y protege datos sensibles. Sus capacidades:

1. Discovery (descubrimiento): genera perfiles de datos de forma continua sobre BigQuery, Cloud SQL, Cloud Storage y otras fuentes, con nivel de sensibilidad y riesgo por tabla o bucket. Responde a «¿dónde tengo PII en toda la organización?».
2. Inspection (inspección): busca infoTypes (más de un centenar de detectores integrados: CREDIT_CARD_NUMBER, EMAIL_ADDRESS, IBAN_CODE, PHONE_NUMBER, PERSON_NAME, y específicos de España como SPAIN_DNI_NUMBER, SPAIN_NIE_NUMBER, SPAIN_NIF_NUMBER o SPAIN_SOCIAL_SECURITY_NUMBER), con probabilidad (VERY_UNLIKELY a VERY_LIKELY). Admite custom infoTypes con diccionarios o expresiones regulares y reglas de contexto. Se ejecuta sobre contenido enviado a la API (en línea) o como jobs sobre almacenamiento.
3. De-identification (desidentificación): transforma los hallazgos.
4. Risk analysis: mide el riesgo de reidentificación de un conjunto (k-anonimato, l-diversidad).

Técnicas de desidentificación:

Las transformaciones reversibles usan una llave que, en producción, debe estar envuelta con Cloud KMS (kmsWrapped), lo que conecta SDP con la separación de funciones del módulo anterior: quien puede reidentificar es quien tiene permiso sobre la llave.

PII y datos de tarjetas: patrón de arquitectura

flowchart LR
  APP["Aplicación de pagos"] --> TOK["Servicio de tokenización (proyecto CDE)"]
  TOK --> KMS["Cloud KMS / Cloud HSM"]
  TOK --> VAULT[("Bóveda de PAN cifrados")]
  TOK -->|"token"| REST["Resto de sistemas (fuera del alcance PCI)"]
  REST --> BQ[("BigQuery analítica")]
  SDP["SDP: descubrimiento continuo"] -.->|"vigila que no aparezcan PAN"| BQ
  subgraph VPCSC["Perímetro VPC SC del CDE"]
    TOK
    VAULT
  end

Principios:

• Reducir el alcance: solo un componente pequeño ve el número de tarjeta (PAN); el resto trabaja con tokens. Menos sistemas en el CDE = auditoría más barata.
• Aislar el CDE: proyecto y VPC propios, firewall restrictivo, perímetro de VPC Service Controls, sin IP públicas.
• Nunca registrar PAN en logs: usa SDP para inspeccionar y redactar antes de guardar, y para descubrir PII donde no debería estar.
• Auditar: Admin Activity y Data Access logs activados en el CDE, exportados a un proyecto de auditoría con retención de al menos lo que exija la norma.

Auditorías y retención de logs

Un auditor pedirá pruebas de quién accedió a qué, quién cambió qué y durante cuánto tiempo lo conservas. Diseño típico:

1. Activa los Data Access logs en los servicios con datos regulados (están desactivados por defecto salvo en BigQuery).
2. Crea un aggregated sink en la organización hacia un log bucket en un proyecto de auditoría con retención configurada (entre 1 y 3.650 días), y/o hacia Cloud Storage con Bucket Lock (política de retención bloqueada: nadie puede borrar antes de tiempo, ni siquiera un administrador) para conservación a largo plazo y barata, y/o hacia BigQuery para consultas.
3. Restringe el acceso al proyecto de auditoría (separación de funciones).
4. Añade Access Transparency para las acciones del personal de Google.
5. Usa Security Command Center (Premium) para informes de cumplimiento frente a estándares (CIS, PCI DSS, NIST, ISO) y Assured Workloads para detectar infracciones del paquete de control.

Recuerda las retenciones por defecto: _Required 400 días (Admin Activity y System Event), _Default 30 días.

Parte B: IA en Google Cloud

La segunda parte cubre los apartados 1.3, 2.4, 2.5 y la seguridad de la IA del 3.1.

Mapa de nombres (actualizado a septiembre de 2026)

En la conferencia Cloud Next del 22 de abril de 2026, Google renombró y amplió Vertex AI como Gemini Enterprise Agent Platform (abreviado «Agent Platform»). Las cargas de Vertex AI siguen funcionando sin cambios; las APIs usan el mismo endpoint aiplatform.googleapis.com. Tabla de equivalencias:

Gemini Enterprise Agent Platform

Es la plataforma para desarrolladores: modelos, agentes y ML clásico en un mismo sitio, con facturación por consumo. La documentación la organiza en cuatro pilares:

Modelos Gemini

Gemini es la familia de modelos multimodales de Google (texto, imagen, audio, vídeo y código como entrada; ventanas de contexto muy largas). Se ofrece en variantes Pro (máxima capacidad de razonamiento), Flash (equilibrio calidad, latencia y coste) y Flash-Lite (lo más barato y rápido). Las versiones cambian a menudo (a septiembre de 2026 conviven, entre otras, generaciones 2.5, 3.x y 3.5): en el examen importa el criterio (Pro para razonamiento complejo, Flash para volumen y latencia), no el número de versión. Las opciones de consumo incluyen pago por token (estándar, prioridad, flex o por lotes con descuento) y Provisioned Throughput (capacidad reservada para cargas con volumen alto y predecible).

ML de principio a fin (apartado 2.4)

Aunque el foco mediático sea la IA generativa, el examen sigue preguntando por el ciclo de ML clásico:

flowchart LR
  D["Datos: BigQuery, Cloud Storage"] --> FS["Agent Platform Feature Store"]
  FS --> TR["Agent Platform Training (custom o AutoML)"]
  TR --> MR["Model Registry"]
  MR --> EP["Endpoint online o predicción por lotes"]
  EP --> MON["Monitorización de modelos"]
  PIPE["Agent Platform Pipelines (Kubeflow Pipelines o TFX)"] -.->|"orquesta y registra metadatos"| FS
  PIPE -.-> TR
  PIPE -.-> MR
  PIPE -.-> EP

• Agent Platform Pipelines: orquesta el ciclo de ML sin servidores que gestionar, con pipelines definidos en Kubeflow Pipelines o TensorFlow Extended (TFX). Guarda parámetros y artefactos en ML Metadata (linaje: qué datos y qué código produjeron qué modelo). Es la respuesta a «automatizar y reproducir el reentrenamiento» (MLOps).
• Feature Store: gestiona y sirve features; usa BigQuery como almacén offline y ofrece online serving de baja latencia, evitando el desfase entre entrenamiento e inferencia (training-serving skew).
• Preparar la integración de datos: los datos de entrenamiento suelen vivir en BigQuery o Cloud Storage; Dataflow y Managed Service for Apache Spark (antes Dataproc) hacen la transformación; los componentes de Pipelines integran BigQuery ML, Dataflow y Managed Service for Apache Spark.
• Training: entrenamiento personalizado (tu código en contenedores con CPU, GPU o TPU, incluido entrenamiento distribuido) o AutoML (sin código, a partir de datos etiquetados).
• Serving: endpoints online (autoescalado, GPU opcional) o predicción por lotes; para modelos abiertos grandes también se sirve en GKE o en Cloud Run con GPU.

AI Hypercomputer

AI Hypercomputer no es un producto que se compre, sino la arquitectura integrada de Google para entrenamiento e inferencia a gran escala: hardware optimizado (TPUs y GPUs de NVIDIA, red de alto rendimiento, almacenamiento rápido), software abierto (JAX, PyTorch, vLLM, GKE, Slurm) y modelos de consumo flexibles.

Modelos de consumo (documentación de AI Hypercomputer):

¿API preentrenada, modelo generativo o entrenamiento propio? (apartado 2.5)

Las APIs preentrenadas resuelven tareas concretas con una llamada, sin ML propio:

Árbol de decisión:

Orden de preferencia de arquitecto: lo más gestionado que cumpla el requisito. API preentrenada → generativo con prompt → RAG/grounding → ajuste → entrenamiento propio.

Gemini Enterprise

Gemini Enterprise (antes Google Agentspace) es el producto para usuarios finales de la empresa, con licencias por usuario (ediciones Business, Standard, Plus, Frontline y pago por uso): un asistente y buscador corporativo con conectores a Google Workspace, Microsoft SharePoint, Jira, Confluence, ServiceNow, Salesforce y otros, que respeta los permisos de cada usuario sobre los datos de origen. Incluye:

• Agentes preconstruidos (como Deep Research o Idea Generation) en una galería de agentes.
• Agent Designer: creación de agentes sin código.
• Publicación de agentes propios construidos con ADK y desplegados en Agent Runtime.
• Gemini Notebook Enterprise (antes NotebookLM Enterprise): cuadernos de investigación sobre fuentes elegidas a mano, con respuestas limitadas a esas fuentes, resúmenes y audio. Incluido en las ediciones Standard y Plus, y disponible por separado.

La diferencia clave: Gemini Enterprise es para que los empleados usen IA sobre los datos de la empresa; Agent Platform es para que los desarrolladores construyan aplicaciones y agentes.

RAG, búsqueda empresarial y grounding

Un LLM solo sabe lo que aprendió al entrenarse y puede alucinar. Grounding (fundamentación) ancla la respuesta en fuentes verificables y devuelve citas. Opciones:

• Grounding with Google Search: respuestas actualizadas con información pública de la web.
• Grounding con tus datos: sobre un almacén de Agent Search (antes Vertex AI Search) o con RAG Engine.
• Grounding with Google Maps para datos geográficos.

RAG (retrieval-augmented generation): antes de preguntar al modelo, se recuperan los fragmentos relevantes de tus documentos (normalmente por similitud de embeddings en una base vectorial) y se añaden al prompt.

flowchart LR
  DOC["Documentos: Cloud Storage, BigQuery, web"] --> IDX["Troceado + embeddings + índice (Agent Search, RAG Engine o Vector Search)"]
  U["Pregunta del usuario"] --> RET["Recuperación de fragmentos relevantes"]
  IDX --> RET
  RET --> LLM["Gemini con prompt + contexto"]
  LLM --> R["Respuesta con citas"]

Frente a fine-tuning (ajuste): el ajuste cambia cómo responde el modelo (estilo, formato, tareas especializadas); RAG cambia qué sabe en el momento de responder. Para conocimiento que cambia a menudo (catálogo, normativa interna), RAG es casi siempre la respuesta.

Seguridad de la IA (apartado 3.1)

Riesgos específicos: inyección de prompts y jailbreaks, fuga de datos sensibles en prompts o respuestas, contenido dañino, envenenamiento de datos de entrenamiento, robo de modelos y agentes con demasiados permisos.

• Model Armor: filtra prompts y respuestas de cualquier LLM (en Google Cloud o en otras nubes) mediante plantillas con umbrales de confianza: inyección de prompts y jailbreak, categorías de IA responsable (odio, acoso, contenido sexual explícito, peligroso), URLs maliciosas y datos sensibles (usa Sensitive Data Protection). Se integra con Agent Platform y con Agent Gateway.
• Sensitive Data Protection: desidentifica datos antes de usarlos para ajustar modelos, antes de mandarlos en un prompt o en los logs de conversaciones.
• Despliegue seguro de modelos: VPC Service Controls alrededor de Agent Platform (evita exfiltración de datos y modelos), Private Service Connect para endpoints privados, CMEK, cuentas de servicio mínimas o Agent Identity por agente, Binary Authorization y Artifact Analysis para las imágenes de serving, escaneo de vulnerabilidades de cargas de IA en Security Command Center.
• Gobernanza del dato: Google indica en sus condiciones que no usa los datos de clientes de Google Cloud para entrenar sus modelos sin permiso o instrucción previa del cliente.
• IA responsable: filtros de seguridad configurables en Gemini, evaluación de modelos y agentes, supervisión humana en decisiones de impacto, transparencia y documentación. Google publica sus AI Principles.
• Secure AI Framework (SAIF): marco conceptual de Google para asegurar sistemas de IA. Sus ideas principales: extender a la IA los fundamentos de seguridad existentes, llevar la IA al ámbito de detección y respuesta, automatizar defensas, armonizar controles a nivel de plataforma, adaptar controles con ciclos de retroalimentación rápidos (p. ej. red teaming) y contextualizar el riesgo de la IA en los procesos de negocio.

Gemini Cloud Assist (apartados 1.2 y 5.1)

Gemini Cloud Assist es el asistente de IA integrado en la consola de Google Cloud para operar la nube (no para construir aplicaciones de IA):

• Diseño: junto con Application Design Center, convierte una descripción en lenguaje natural en un diagrama de arquitectura y en plantillas Terraform o comandos.
• Resolución de problemas: investigaciones que analizan logs, métricas y configuración para proponer causas raíz; pueden lanzarse desde políticas de alertas.
• Optimización de costes: explica picos de gasto y propone ahorros.
• Algunas funciones son gratuitas y otras requieren licencia; consulta la página de precios de Gemini para Google Cloud.

Trampas típicas del examen

• Certificación de Google = cumplimiento tuyo: falso. Google certifica su infraestructura; tú configuras y demuestras tus controles.
• HIPAA: no basta con «usar Google Cloud»: hay que firmar el BAA y usar solo servicios cubiertos.
• Seudonimizar no es anonimizar: un token reversible sigue siendo dato personal para el RGPD.
• Residencia: gcp.resourceLocations limita dónde se crean recursos nuevos; no mueve los existentes.
• Access Transparency (ver lo que hace Google) frente a Access Approval (aprobar antes) frente a Cloud Audit Logs (lo que hace tu gente).
• PCI DSS: la mejor respuesta suele reducir el alcance (tokenización y aislamiento), no cifrar todo en todas partes.
• Retención de años para auditoría: sink a log bucket con retención larga o Cloud Storage con Bucket Lock, no el _Default de 30 días.
• Vertex AI = Agent Platform, Agentspace = Gemini Enterprise, Vertex AI Search = Agent Search, NotebookLM = Gemini Notebook.
• Gemini Enterprise frente a Agent Platform: empleados que usan IA frente a desarrolladores que la construyen.
• Entrenar un modelo propio cuando basta una API preentrenada o un prompt: suele ser la respuesta incorrecta por coste y operativa.
• Fine-tuning para conocimiento que cambia: casi siempre es mejor RAG o grounding.
• Spot para entrenamiento sin checkpoints: mala idea; perderás el progreso en cada interrupción.
• Model Armor frente a filtros de seguridad del modelo: Model Armor es una capa independiente del modelo, con plantillas centralizadas y aplicable a cualquier LLM.

Resumen

• Google certifica su plataforma (ISO 27001/27017/27018, SOC 2, PCI DSS, ENS alta…); tú configuras tus controles y firmas los acuerdos (Cloud DPA, BAA).
• RGPD/LOPDGDD: ubicación UE, minimización, seudonimización con SDP, CMEK, IAM mínimo y auditoría; notificación de brechas en 72 h.
• Residencia con gcp.resourceLocations; paquetes regulados con Assured Workloads; acceso de Google con Access Transparency y Access Approval; llaves fuera con Cloud EKM y Key Access Justifications.
• Soberanía en Europa: Google Cloud Data Boundary, Google Cloud Dedicated (S3NS en Francia, Thales en Alemania) y Google Distributed Cloud.
• Sensitive Data Protection: descubrir, inspeccionar (infoTypes, incluidos DNI/NIE españoles), desidentificar (enmascarar, tokenizar, FPE) y medir riesgo.
• Gemini Enterprise Agent Platform: Build (ADK, Agent Studio, Model Garden, RAG Engine), Scale (Agent Runtime), Govern (Agent Identity, Agent Gateway, Model Armor), Optimize; ML con Pipelines, Feature Store, Training y Model Registry.
• AI Hypercomputer: GPU o TPU con el modelo de consumo adecuado (Spot, Flex-start, reservas, CUD).
• Preferencia: API preentrenada → Gemini con prompt → RAG/grounding → ajuste → entrenamiento propio.
• Gemini Enterprise para empleados (agentes, conectores, Gemini Notebook Enterprise); Agent Search para búsqueda gestionada y RAG.
• Seguridad de la IA: Model Armor, SDP, VPC SC, identidades mínimas por agente y el marco SAIF.

Practica lo aprendido

Documentación oficial para ampliar

• Compliance resource center
• Assured Workloads overview
• Access Transparency
• Access Approval
• Sovereign Cloud from Google
• Sensitive Data Protection overview
• Gemini Enterprise Agent Platform overview
• Agent Platform Pipelines
• AI Hypercomputer consumption models
• What is Gemini Enterprise?
• Model Armor overview
• Generative AI pricing (Agent Platform)
• Gemini Cloud Assist overview