Cómo ver qué herramientas de IA tienen acceso a su Google Workspace

Puede ver todas las herramientas de IA con acceso OAuth a su Google Workspace desde la consola de administración, en Security → Access and data control → API controls → App access control. Ahí se enumeran todas las aplicaciones de terceros autorizadas en su dominio —incluidos asistentes de IA, extensiones de navegador y bots que toman notas de reuniones— junto con los datos de Google que se le han concedido a cada una.

Esta guía recorre esa ruta, muestra lo que la consola realmente indica, dónde se queda corta, y cómo mantener la lista actualizada una vez que la tiene.

¿Dónde encuentro el acceso de aplicaciones de terceros en la consola de administración de Google?

1. Inicie sesión en admin.google.com como superadministrador o como administrador con el privilegio de Services.
2. Vaya a Menu → Security → Access and data control → API controls.
3. Haga clic en Manage App Access (también denominado App access control en algunas versiones de la consola).

Llegará a una lista dividida en Configured apps (aplicaciones para las que su organización ha establecido explícitamente un nivel de acceso) y Accessed apps (todas las aplicaciones actualmente en uso, las haya configurado o no). Para cada aplicación puede ver:

• El nombre de la aplicación, el editor y el ID de cliente OAuth.
• Si cuenta con la insignia de verificación de aplicaciones de Google.
• Los ámbitos (scopes) individuales de servicios de Google que solicita —Drive, Gmail, Calendar, Admin Directory, etc.—, desplegables por aplicación.
• Cuántos usuarios de su dominio la han autorizado.
• El nivel de acceso que puede establecer: Trusted, Limited, Specific Google data o Blocked.

También puede exportar la lista completa como CSV y aplicar distintos niveles de acceso a distintas unidades organizativas en lugar de a todo el dominio a la vez.

¿Cómo distingo cuáles de estas aplicaciones son herramientas de IA?

La consola de Google no etiqueta nada como "IA": enumera todas las aplicaciones conectadas mediante OAuth de la misma manera, ya se trate de un complemento de hoja de cálculo o de un asistente basado en un modelo de lenguaje de gran tamaño. En la práctica, las herramientas de IA aparecen bajo nombres como los de un proveedor de IA directamente (OpenAI, Anthropic, Perplexity), un bot de notas de reuniones (Otter.ai, Fireflies, Fathom), un asistente de escritura (Grammarly, Jasper), o un complemento más específico ("GPT for Sheets and Docs", "AI Email Writer") cuyo nombre de editor no da ninguna pista de lo que hace. Reconocerlas es un ejercicio manual de reconocimiento de patrones: revise los nombres de las aplicaciones y de los editores, y verifique los ámbitos solicitados —una aplicación que pide drive.readonly o gmail.readonly junto a un nombre que no reconoce merece una revisión más detenida, sea cual sea su categoría.

¿Cómo verifico qué herramientas de IA autorizó una persona en concreto?

La vista a nivel de dominio descrita arriba le indica que una aplicación tiene usuarios; no le indica *quién* la autorizó ni *cuándo*. Para eso:

1. Vaya a Menu → Directory → Users y abra la cuenta de la persona.
2. Abra su pestaña Security.
3. Desplácese hasta Connected applications.

Esa sección enumera todas las aplicaciones de terceros que este usuario en particular ha autorizado, el nivel de acceso (los ámbitos que puede usar) y la fecha de autorización. Un administrador con el privilegio User Security Management puede revocar cualquiera de estos permisos directamente desde esa página. Este es el único lugar donde la consola muestra *cuándo* se autorizó una aplicación, pero implica revisar a las personas una por una, sin exportación masiva y sin manera de filtrar solo "herramientas de IA".

¿Cuáles son las limitaciones reales de hacer esto manualmente?

La pantalla de App access control a nivel de dominio agrega recuentos pero omite el detalle por usuario; la pantalla de Connected Applications por usuario tiene el detalle pero no una vista masiva. Ninguna de las dos le indica:

• Si el acceso todavía se está usando, o si se concedió una vez y se olvidó.
• Qué ha hecho realmente la aplicación con los datos a los que puede acceder: la consola muestra lo que *puede* acceder, no lo que *ha* accedido.
• Cómo ha cambiado el panorama con el tiempo, ya que no existe una línea de tiempo histórica de permisos añadidos o ámbitos ampliados.
• Cuáles de las aplicaciones listadas son herramientas de IA, a menos que usted mismo reconozca cada nombre de proveedor.

Para un Workspace con un puñado de aplicaciones conectadas, revisar ambas pantallas a mano es viable. A partir de unas pocas decenas de aplicaciones y unos cientos de usuarios, mantener la lista actualizada deja de ser una tarea puntual y se convierte en una tarea recurrente: la misma información, verificada una y otra vez, indefinidamente. Y ambas pantallas requieren un rol de administrador con el privilegio adecuado (Services para la vista a nivel de dominio, User Security Management para la vista por usuario); un Workspace con varios administradores igualmente necesita a una persona que revise ambas con regularidad, no una tarea que recaiga de forma natural en quien la note primero.

¿Qué no puede indicarle la vista manual, y cómo responde a eso 8200.dev?

La vía manual responde a *qué puede acceder a los datos*. No responde a *quién lo usó, cuándo, y si todavía es necesario*: las preguntas que realmente determinan si una aplicación debería conservar su acceso. Agent Guard de 8200.dev inventaría cada agente de IA y aplicación conectada mediante OAuth en todas sus fuentes conectadas en una única vista actualizada continuamente, califica el riesgo de cada una y explica el hallazgo en lenguaje sencillo en lugar de con una cadena de ámbitos. El descubrimiento es de solo lectura: conectar Google Workspace utiliza un ámbito de solo lectura sobre metadatos de Drive, y el inventario más profundo de aplicaciones OAuth mostrado arriba está disponible una vez que una organización activa la auditoría de aplicaciones OAuth, la cual vuelve a autorizar con los ámbitos adicionales de solo lectura del Admin SDK que Google requiere para esa vista específica; nada de esto modifica el acceso por sí solo, y cualquier acción permanece como una recomendación hasta que la organización decida actuar sobre ella.

Consulte la lista completa de conectores para ver cómo esto se extiende más allá de Google Workspace a Microsoft 365, Slack, GitHub y los propios proveedores de IA.