Google Gemini en la empresa: lo que exige la Ley de Inteligencia Artificial
Google Gemini en la nube empresarial se enfrenta al Reglamento de Inteligencia Artificial (AI Act).
8 Min. Tiempo de lectura
Google Gemini ha llegado a la nube empresarial, y al mismo tiempo el AI Act ya es aplicable. Quien construye pipelines de inferencia sin planificar las obligaciones para los modelos de IA de propósito general está creando una arquitectura que, como mínimo, será desmantelada en una auditoría.
Lo más importante en resumen
- Las obligaciones del AI Act no son una ampliación de la GDPR. Los modelos GPAI tienen sus propias obligaciones en materia de transparencia, documentación y riesgos. Un DPA con Google no las cubre.
- Vertex AI no es automáticamente conforme. El servicio gestionado facilita el registro y el pinning de regiones, pero el responsable de la arquitectura sigue siendo el cliente, quien debe encargarse de las tarjetas de modelo, la evaluación de casos de uso y el FRIA.
- La gemma autohosted cuesta por horas de GPU más el overhead del clúster. Quien utiliza Gemini en sus propias GPUs a través de Model Garden asume el costo de cumplimiento y los gastos operativos continuos de GPU. Esto solo se justifica cuando se alcanza un volumen claro.
Relacionado:Android 17 lleva a Gemini bajo el sistema operativo / EKS 1.36 se vuelve caro sin disciplina FinOps
Qué cambia regulatoriamente Google Gemini en la nube empresarial
¿Qué es una arquitectura de inferencia conforme al AI Act? Una arquitectura de inferencia es conforme al AI Act cuando cumple técnicamente con las obligaciones establecidas en el AI Act de la UE para los modelos de IA de propósito general y para las aplicaciones de alto riesgo. Estas obligaciones incluyen la transparencia del modelo, el registro de las entradas y salidas en casos de uso regulados, la evaluación de riesgos para cada caso de uso, la evaluación del impacto sobre los derechos fundamentales en las entidades públicas y una separación clara entre los datos de entrenamiento y los de inferencia.
El AI Act no trata a Google Gemini como un producto, sino como un modelo de IA de propósito general. Las obligaciones afectan tanto al proveedor como al implementador. El proveedor es Google. El implementador es cualquier empresa que utilice Gemini en un caso de uso específico. Esto hace que parte de la responsabilidad recaiga nuevamente en los equipos de la nube de Alemania, Austria y Suiza, quienes consumen el modelo. En una auditoría, no basta con decir “Google es responsable”. Quien llama al modelo debe clasificar ese llamado, documentarlo y asignarle una clase de riesgo.
Esta no es una teoría. Los primeros procedimientos de multas ya están en marcha, y las publicaciones oficiales de la Oficina Europea de IA lo demuestran explícitamente. Quien planea una arquitectura de inferencia sin considerar la dimensión del AI Act está contrayendo deudas.
Dónde Vertex AI facilita el cumplimiento y dónde no
Vertex AI es la plataforma de inferencia gestionada por Google que incluye modelos Gemini. Resuelve tres problemas de forma automática: el pinning de regiones hacia ubicaciones en la UE, el registro con los logs de auditoría de la nube y las cláusulas contractuales estándar en el Addendum de Procesamiento de Datos. Lo que Vertex AI no resuelve es la transparencia del modelo para el propio caso de uso, la clasificación de riesgos según el AI Act o la evaluación del impacto sobre los derechos fundamentales en aplicaciones de alto riesgo.
En términos concretos, una aplicación de recursos humanos con Gemini para la revisión de solicitudes de empleo es una aplicación de alto riesgo según el Anexo III del AI Act. Vertex AI no otorga esa clasificación. El implementador debe realizarla por su cuenta, asegurarse de registrar las decisiones del modelo para cada solicitud y documentar la visibilidad de las tasas de falsos positivos y falsos negativos. Si la supervisión pregunta, responder con “Vertex AI registra todo eso” es insuficiente.
Gemini-Endpoints autohospedados: cuándo resultan rentables
Google ofrece modelos Gemini en varias variantes, incluyendo familias de modelos abiertos como Gemma 2 y 3, así como endpoints propietarios que solo funcionan en Vertex AI. Por lo tanto, la opción autohospedada no es una elección directa. Para las variantes de Gemma existen verdaderas vías on-premise mediante Triton Inference Server o vLLM en GPUs propias. En cambio, para las clases propietarias de Gemini Pro esto no está disponible; permanecen vinculadas exclusivamente a Vertex.
Así, la pregunta “autohospedado o gestionado” se reduce, para la mayoría de los casos de uso, a la elección entre Gemma y los modelos propietarios, donde únicamente queda Vertex. Además, la cuestión de cumplimiento se traslada al propio despliegue del endpoint dentro del proyecto: región, registro de actividades, vínculos con IAM y seguimiento de auditoría.
| Dimensión | Vertex AI gestionado | Gemma autohospedado sobre GKE |
|---|---|---|
| Modelo de costos | Por token, aproximadamente 0,3 céntimos por cada 1.000 tokens de salida para Gemini Flash, significativamente más alto para Gemini Pro | Precio por hora de GPU más sobrecarga del clúster, desde aproximadamente 3 euros por hora de H100 bajo demanda |
| Esfuerzo de cumplimiento | Región y registro de actividades listos desde el principio; clasificación conforme a la Ley de IA a cargo del cliente | Completa cadena de cumplimiento a cargo del cliente, sin registro por parte del proveedor |
| Mapa del modelo | Publicado por Google, correspondiente al desplegador | Mapa del modelo Gemma junto con documentación propia de ajustes personalizados |
| Soberanía de datos | Fijación regional en la UE; acceso autoridades según legislación estadounidense posible | Control total, siempre que el proveedor de GPU no esté sujeto a leyes estadounidenses |
| Uso recomendado a partir de | De inmediato, para la mayoría de los casos de uso | A partir de aproximadamente 10 millones de tokens diarios o cuando exista una clara exigencia de soberanía de datos |
Fuente: Páginas de precios de Google Cloud y análisis propio basado en tarifas de GPUs de hiperescaladores, actualizado a mayo de 2026.
En la práctica, el camino autohospedado rara vez resulta rentable por debajo de los 10 millones de tokens diarios. Debajo de ese umbral, el trabajo adicional requerido por DevOps, MLOps y cumplimiento supera los costos adicionales de tokens en Vertex. Por encima de este límite, las relaciones cambian radicalmente, especialmente cuando se exige soberanía de datos o se necesitan rutas específicas de ajuste que Vertex no permite.
Las cinco obligaciones de la Ley de IA que deben reflejarse en toda arquitectura Gemini
Estas cinco obligaciones pueden plasmarse técnicamente, pero no sin esfuerzo. El registro es la disciplina más económica; la FRIA y la clasificación de riesgos son las más costosas, pues requieren colaboración jurídica. Una arquitectura de inferencia que no planifique estas obligaciones en su configuración inicial tendrá que añadirlas posteriormente bajo presión.
Por qué los costes de GPU impulsan la decisión arquitectónica
Quien aloje Gemma por cuenta propia compra capacidad de GPU que no puede fallar. Una H100 como nodo único no es una arquitectura productiva. La alta disponibilidad exige al menos tres nodos en dos zonas, capacidad de reserva para ejecuciones de entrenamiento y ajuste, y un equilibrador de carga con afinidad. Los nominales 3,80 euros por hora se convierten en una producción real en seis a ocho euros efectivos, según la utilización.
No es incorrecto, solo es caro. Quien opere con un volumen claro de inferencia con cifras de tokens de seis a siete dígitos diarios puede hacer viable la ruta de alojamiento propio. Quien comience de forma experimental avanzará más rápido y barato con Vertex, ganando tiempo para establecer la base de cumplimiento antes de decidir la cuestión de las GPU.
Lo que los equipos de nube DACH deben consolidar en los próximos seis meses
Tres decisiones determinan si la integración de Gemini de una empresa es conforme con el AI Act. Primero: inventario de casos de uso con clase de riesgo por aplicación, documentado y localizable durante la auditoría. Segundo: decisión de plataforma, si Vertex AI se considera predeterminado o ciertos casos de uso se despliegan en Gemma autoalojado. Tercero: matriz de responsabilidades que hace explícito qué aporta Google y qué asume el operador.
Sin estas tres decisiones surge una arquitectura que crece reaccionando a cada nueva necesidad, sin que la sustancia de cumplimiento evolucione al mismo ritmo. Esta es la fuente de error más frecuente. Quien toma las decisiones antes del segundo caso de uso construye sobre bases sólidas. Quien espera, construye tarde.
Preguntas frecuentes
¿Basta la ubicación de datos UE de Vertex AI para el cumplimiento RGPD?
La ubicación de datos UE es una condición necesaria, pero no suficiente. Google, como empresa estadounidense, sigue estando sujeta a la CLOUD Act, lo que exige medidas de protección contractuales y técnicas adicionales. Cláusulas contractuales estándar junto con cifrado mediante claves gestionadas por el cliente a través de Cloud KMS o External Key Manager son la vía habitual. Sin esta complementación, el cumplimiento RGPD con datos sensibles resulta vulnerable.
¿Qué casos de uso de Gemini se consideran de alto riesgo según el AI Act?
El Anexo III del AI Act enumera áreas concretas: infraestructuras críticas, educación y formación profesional, empleo y decisiones de personal, acceso a servicios públicos y prestaciones sociales, policía, control fronterizo, administración de justicia. Quien emplea Gemini en uno de estos ámbitos desarrolla una aplicación de alto riesgo, con obligación de evaluación FRIA, registro mejorado y notificación a las autoridades.
¿Deben las empresas con menos de 250 empleados cumplir el AI Act?
Sí, el AI Act no diferencia principalmente por tamaño empresarial, sino por clase de riesgo del caso de uso. Las pymes obtienen ciertas flexibilidades en documentación, pero las obligaciones centrales siguen vigentes. Una startup de tres personas que utilice Gemini para preselección de candidaturas desarrolla una aplicación de alto riesgo con todas sus obligaciones.
¿En qué se diferencia el AI Act del RGPD en cuanto a requisitos de registro?
El RGPD exige un registro de actividades de tratamiento y logs de auditoría para datos sensibles. El AI Act requiere además un registro de actividad del modelo con entradas, salidas, valores de confianza e información de versiones, destinado específicamente a garantizar la trazabilidad de la decisión de IA. Las obligaciones se solapan, pero no coinciden totalmente. Quien solo implemente logging RGPD no tendrá automáticamente logging conforme al AI Act.
Imagen principal: generada por IA (mayo de 2026)
Fuente de la imagen: generada por IA (mayo de 2026), certificado C2PA incrustado en la imagen
Traducido del original en alemán con inteligencia artificial. La versión alemana es la de referencia.
