Gemini ya actúa dentro de Microsoft 365. ¿Su suite de colaboración sigue eligiendo su plataforma de agentes?

Durante años, la elección de la plataforma de IA empresarial tuvo un atajo: si la empresa trabaja con Microsoft 365, usa Copilot; si trabaja con Google Workspace, usa Gemini. La suite de colaboración elegía el asistente.

Ese atajo se está debilitando. El 18 de septiembre, Google añadió a Gemini Enterprise acciones en vista previa que permiten a sus agentes actuar, y no solo leer, dentro de los servicios principales de Microsoft.

Qué cambió

Según las notas de versión de Google, estas acciones están en vista previa pública:

• OneDrive: copiar carpetas, mover y renombrar archivos y carpetas, compartir, actualizar propiedades de archivos.
• Outlook: crear y actualizar calendarios, responder a invitaciones.
• SharePoint: crear, consultar y actualizar elementos de lista, listar listas y campos, compartir recursos, actualizar propiedades de archivos y páginas, descartar desprotecciones de documentos.
• Teams: crear canales y chats, añadir miembros a canales, actualizar canales, chats y mensajes, crear turnos y registrar ausencias.

Las notas del mismo mes incluyen dos cambios de gobernanza que conviene leer a la vez. El 21 de septiembre, Google permitió a los administradores transferir la propiedad de agentes compartidos, desactivando programaciones y disparadores hasta que el nuevo responsable los reactive. El 28 de septiembre llegaron los permisos IAM por recurso, para restringir aplicaciones y data stores concretos sin abrir todo el proyecto de Google Cloud.

Ubicación de los datos: España frente a Latinoamérica

Aquí la respuesta cambia según el mercado. Las notas de septiembre muestran modelos disponibles en las ubicaciones global, US y EU, y explican que, en regiones sin soporte dentro del país, el administrador solo puede enrutar el tráfico al endpoint global después de aceptar una advertencia.

Para organizaciones en España, la multirregión EU ofrece un camino para mantener el procesamiento en Europa, algo relevante bajo el RGPD. Para organizaciones en Latinoamérica, las notas consultadas no mencionan regiones locales, así que el procesamiento ocurrirá fuera del país; cada legislación nacional de protección de datos define cómo tratar esa transferencia. En ambos casos, es una decisión para el equipo de privacidad, no un clic en la consola.

1. Usuario en Microsoft Entra
2. Agente de Gemini Enterprise
3. Conector y mapeo de identidad
4. Permiso en Microsoft 365
5. Acción en SharePoint, Teams u Outlook

• Google Cloud: Agente de Gemini Enterprise · Conector y mapeo de identidad
• Microsoft 365: Permiso en Microsoft 365 · Acción en SharePoint, Teams u Outlook

Plataforma de agentesSuite de colaboración

El coste real de un agente entre proveedores

Que un agente de un proveedor actúe en la suite de otro ya es técnicamente posible. Operativamente, multiplica el trabajo justo donde se decide si seguridad lo aprueba:

Dos sistemas de identidad. Los usuarios están en Microsoft Entra. La plataforma de agentes tiene su propio modelo de identidad e IAM. Alguien debe mapear en nombre de quién actúa el agente en Microsoft 365 y mantener ese mapeo correcto cuando las personas entran, cambian de área o se van.

Traducción de permisos. Cuando un agente de Gemini actualiza una lista de SharePoint, la pregunta no es si puede, sino con qué permisos, y si coinciden con lo que podría hacer directamente el usuario que lo pidió.

Dos registros de auditoría. La acción empieza en una plataforma y se ejecuta en otra. Una investigación necesita ambos lados, correlacionados.

Dos modelos de gobernanza. Inventario de agentes, responsables, reglas de aprobación y roles de administración existen en ambos lados, con nombres distintos para controles parecidos.

Cuándo tiene sentido

Hay buenas razones para asumir ese coste:

• Los datos y las cargas de IA ya están en Google Cloud, mientras la colaboración funciona en Microsoft 365, y los agentes tienen que estar cerca de los datos.
• La organización evita a propósito depender de un único proveedor de IA y tiene capacidad de gobernanza para operar dos.
• Una capacidad concreta existe en una plataforma y no en la otra, y el caso de uso lo justifica.

Tiene menos sentido cuando el único argumento es la paridad de funciones, o cuando nadie es responsable del mapeo de identidades y de la auditoría entre plataformas.

Una pregunta mejor que “¿qué suite?”

La suite de colaboración se está convirtiendo en un destino de integración entre varios. La decisión de plataforma debería seguir otras tres preguntas:

1. ¿Dónde están los datos y el proceso sobre los que el agente tiene que actuar?
2. ¿Dónde puede aplicar identidad, permisos y auditoría de forma más coherente para ese caso?
3. ¿Quién lo va a operar, y puede ese equipo sostener otro modelo de gobernanza?

Ningún proveedor “gana” por defecto. Lo que cambia es que la decisión pasa a ser suya, y deliberada. Es también un ejemplo práctico de ser nativo en una plataforma sin depender solo de ella, como explicamos en nuestra guía del stack de 2026.

Qué hacer ahora

• Trate las nuevas acciones como vista previa. Pruebe en un entorno de Microsoft 365 que no sea de producción, con cuentas de prueba.
• Mapee la ruta de identidad de extremo a extremo antes de habilitar cualquier acción de escritura: usuario, agente, conector, permiso en Microsoft 365.
• Decida dónde vive el registro de auditoría combinado y pruébelo con una investigación simulada.
• Revise la configuración de enrutamiento de modelos con el equipo de privacidad.