Como Ver Que Ferramentas de IA Têm Acesso ao Seu Google Workspace

Pode ver todas as ferramentas de IA com acesso OAuth ao seu Google Workspace a partir da consola Admin, em Security → Access and data control → API controls → App access control. Esta lista apresenta todas as aplicações de terceiros autorizadas no seu domínio — incluindo assistentes de IA, extensões de browser e bots de notas de reuniões — juntamente com os dados do Google que cada uma tem permissão para aceder.

Este guia percorre esse caminho, mostra o que a consola realmente revela, onde as suas limitações começam e como manter a lista atualizada depois de a obter.

Onde encontro o acesso de aplicações de terceiros na consola Google Admin?

1. Inicie sessão em admin.google.com como super admin ou como administrador com o privilégio Services.
2. Aceda a Menu → Security → Access and data control → API controls.
3. Clique em Manage App Access (também designado por App access control em algumas versões da consola).

Chega a uma lista dividida em Configured apps (aplicações às quais a sua organização definiu explicitamente um nível de acesso) e Accessed apps (todas as aplicações atualmente em uso, quer tenham sido configuradas ou não). Para cada aplicação, pode ver:

• O nome da aplicação, o editor e o OAuth client ID.
• Se possui o selo de verificação de aplicações da Google.
• Os âmbitos (scopes) individuais dos serviços Google que solicita — Drive, Gmail, Calendar, Admin Directory, entre outros — expansíveis por aplicação.
• Quantos utilizadores no seu domínio a autorizaram.
• O nível de acesso que pode definir: Trusted, Limited, Specific Google data ou Blocked.

Também pode exportar a lista completa como CSV e aplicar diferentes níveis de acesso a diferentes unidades organizacionais, em vez de a todo o domínio de uma só vez.

Como saber quais destas aplicações são ferramentas de IA?

A consola da Google não identifica nada como "IA" — lista todas as aplicações ligadas via OAuth da mesma forma, seja um suplemento de folha de cálculo ou um assistente baseado num modelo de linguagem de grande escala. Na prática, as ferramentas de IA aparecem sob nomes como o de um fornecedor de IA diretamente (OpenAI, Anthropic, Perplexity), um bot de notas de reuniões (Otter.ai, Fireflies, Fathom), um assistente de escrita (Grammarly, Jasper), ou um suplemento mais específico ("GPT for Sheets and Docs", "AI Email Writer") cujo nome do editor não dá qualquer indicação sobre a sua função. Reconhecê-las é um exercício manual de identificação de padrões: analise os nomes das aplicações e dos editores, e verifique os âmbitos (scopes) solicitados — uma aplicação que pede drive.readonly ou gmail.readonly a par de um nome que não reconhece merece uma análise mais atenta, independentemente da categoria.

Como verifico que ferramentas de IA uma pessoa específica autorizou?

A vista global do domínio acima indica que uma aplicação tem utilizadores; não indica *quem*, nem *quando* a autorizou. Para isso:

1. Aceda a Menu → Directory → Users e abra a conta da pessoa.
2. Abra o separador Security.
3. Percorra até Connected applications.

Essa secção lista todas as aplicações de terceiros que este utilizador específico autorizou, o nível de acesso (os âmbitos que pode utilizar) e a data de autorização. Um administrador com o privilégio User Security Management pode revogar qualquer uma destas autorizações diretamente a partir dessa página. Este é o único local onde a consola mostra *quando* uma aplicação foi autorizada — mas implica verificar pessoa a pessoa, sem exportação em massa e sem forma de filtrar apenas por "ferramentas de IA".

Quais são as limitações reais de fazer isto manualmente?

O ecrã de App access control, à escala do domínio, agrega contagens mas não mostra o detalhe por utilizador; o ecrã de Connected Applications por utilizador tem o detalhe mas não uma vista em massa. Nenhum dos dois indica:

• Se o acesso ainda está a ser utilizado, ou se foi concedido uma vez e depois esquecido.
• O que a aplicação fez efetivamente com os dados a que tem acesso — a consola mostra a que pode aceder, não a que já acedeu.
• Como a situação evoluiu ao longo do tempo, já que não existe um histórico cronológico de autorizações concedidas ou de âmbitos alargados.
• Quais das aplicações listadas são ferramentas de IA, a menos que reconheça pessoalmente todos os nomes de fornecedores.

Para um Workspace com um punhado de aplicações ligadas, percorrer manualmente ambos os ecrãs é viável. A partir de algumas dezenas de aplicações e algumas centenas de utilizadores, manter a lista atualizada deixa de ser uma tarefa pontual e passa a ser recorrente — a mesma informação, verificada repetidamente, indefinidamente. E ambos os ecrãs exigem uma função de administrador com o privilégio adequado (Services para a vista global do domínio, User Security Management para a vista por utilizador) — um Workspace com vários administradores continua a precisar de uma pessoa a verificar ambos regularmente, o que não é uma tarefa que recaia naturalmente sobre quem quer que repare no assunto.

O que a vista manual não consegue dizer, e como é que a 8200.dev responde a isso?

O caminho manual responde a *o que pode aceder aos dados*. Não responde a *quem o utilizou, quando, e se ainda é necessário* — as perguntas que realmente determinam se uma aplicação deve manter o seu acesso. O Agent Guard da 8200.dev inventaria todos os agentes de IA e aplicações ligadas via OAuth em todas as suas fontes conectadas, numa única vista atualizada continuamente, atribui a cada um uma pontuação de risco e explica a conclusão em linguagem simples, em vez de uma cadeia de âmbitos técnicos. A descoberta é apenas de leitura: a ligação ao Google Workspace utiliza um âmbito de metadados do Drive apenas de leitura, e o inventário mais aprofundado de aplicações OAuth apresentado acima fica disponível assim que uma organização ativa a auditoria de aplicações OAuth, que reautoriza com os âmbitos adicionais de leitura do Admin SDK que a Google exige para essa vista específica — nada aqui altera o acesso por si só; qualquer ação permanece uma recomendação até a organização optar por a executar.

Consulte a lista completa de conectores para perceber como isto se estende para além do Google Workspace ao Microsoft 365, Slack, GitHub e aos próprios fornecedores de IA.