Para registrar evidências de homologação de uma integração Google, monte um dossiê que ligue cada requisito ao teste executado, ao ambiente identificado e aos arquivos que sustentam a conclusão. Homologação é a verificação de que uma entrega atende aos critérios acordados. Uma captura de tela isolada mostra um momento; o dossiê precisa permitir que outra pessoa entenda o que foi verificado e quais limites permaneceram.
Este guia propõe um pacote de evidências para integrações empresariais com IA, como uma aplicação que consulta documentos autorizados no Google Drive e produz um resumo. O pacote organiza a revisão interna. Ele não equivale a uma verificação oficial de aplicativo pelo Google nem substitui outros processos exigidos para a aplicação.
Resumo rápido
- Defina o requisito e o resultado esperado antes de executar o teste.
- Identifique conta, aplicação, versão e configuração do ambiente.
- Guarde resultados positivos, recusas esperadas e falhas encontradas.
- Separe evidências da aplicação, eventos administrativos e conteúdo de negócio.
- Finalize com um manifesto dos arquivos e uma decisão de aceite com ressalvas explícitas.
Defina o que o dossiê precisa provar
Comece com perguntas verificáveis. A aplicação lê o arquivo selecionado? Recusa uma operação que o usuário não autorizou? Interrompe o processamento quando a autorização deixa de ser válida? O resumo mantém a referência ao documento de origem? Cada pergunta deve apontar para um requisito da entrega e para um critério de aprovação definido antes da execução.
Evite um único requisito chamado integração funciona. Ele não ajuda o auditor a distinguir falha de acesso, erro no processamento e resposta inadequada da IA. Divida o percurso em autenticação, autorização, acesso ao recurso, processamento e apresentação do resultado. Os testes podem compartilhar o mesmo cenário, mas as conclusões precisam permanecer separadas.
Use documentos sintéticos sempre que forem suficientes. Eles permitem inserir nomes e situações conhecidos sem copiar informações de clientes para o relatório. Identifique esses documentos como material de teste e mantenha uma versão de referência. Se o resultado mudar, será possível verificar se mudou a integração ou o próprio conteúdo usado na avaliação. O guia sobre versões de documentos citados em respostas de IA aprofunda a identificação dessas entradas.
O catálogo de integrações Google e Gemini ajuda a localizar a solução envolvida. No dossiê, especifique o caminho real utilizado: chamar uma API própria, usar um aplicativo ou operar um conector são contextos diferentes. Uma evidência de um desses caminhos não comprova automaticamente o comportamento dos demais.
Identifique o ambiente e as permissões testadas
Crie uma ficha de ambiente com data e fuso horário, identificador interno da aplicação, versão do código, configuração relevante, perfil do usuário e responsáveis pelo teste. A ficha deve permitir localizar o projeto correto sem expor credenciais. Se houver mais de um ambiente, use nomes inequívocos e registre onde a execução ocorreu.
Em fluxos OAuth, diferencie as permissões solicitadas daquelas efetivamente concedidas. OAuth é o mecanismo pelo qual a aplicação recebe autorização para acessar recursos em nome de um usuário. A lista oficial de escopos Google ajuda a identificar o acesso representado por cada permissão. Registre os nomes técnicos relevantes para o teste.
A documentação de escopos do Drive distingue acesso por arquivo, como o escopo drive.file, de permissões mais abrangentes. Não classifique uma integração como somente leitura pelo nome comercial ou pela aparência da tela. A conclusão deve considerar a configuração e as operações efetivamente exercitadas.
Também registre o estado inicial: quais documentos existem, quais foram compartilhados com a aplicação e quais ações estão habilitadas. Uma lista obtida depois do teste pode não revelar a situação que o originou. Quando a configuração mudar, gere outra ficha de ambiente e ligue os novos resultados a ela.
Escolha evidências que se complementam
Combine um roteiro legível, resultados estruturados e registros técnicos quando estiverem disponíveis. A tela ajuda a entender o que o usuário viu. O resultado da aplicação ajuda a verificar a resposta recebida. O evento administrativo pode indicar uma autorização ou uma alteração de configuração. Nenhum desses materiais cobre sozinho todo o percurso.
| Evidência | Utilidade | Limitação |
|---|---|---|
| Roteiro de teste | Mostra entradas, passos e expectativa | Não prova que houve execução |
| Saída da aplicação | Registra resultado e identificador do teste | Precisa ser ligada ao ambiente correto |
| Captura de tela | Explica a experiência observada | Pode omitir contexto e detalhes técnicos |
| Registro de auditoria | Ajuda a localizar operações e identidades | Depende do serviço, configuração e acesso |
| Decisão de aceite | Define aprovação e ressalvas | Não substitui os resultados que a sustentam |
A documentação de Cloud Audit Logs distingue tipos de registro. Os logs de acesso a dados exigem habilitação explícita em muitos serviços, com exceções descritas pelo Google. Verifique o serviço e a configuração antes de prometer que toda leitura aparecerá em um relatório. A ausência de um evento, sozinha, não comprova ausência de acesso.
No Google Workspace, a Reports API oferece relatórios de atividade de tokens de autorização. Esse tipo de evento tem finalidade diferente de um relatório de qualidade do resumo. Identifique de onde veio cada registro e qual pergunta ele consegue responder.
Execute testes com rastreabilidade e registre exceções
Atribua um identificador a cada execução, além do identificador do caso de teste. O caso descreve o cenário; a execução informa uma tentativa concreta, com horário e resultado. Se for necessário repetir o teste, crie outra execução. Preservar a primeira tentativa ajuda a explicar uma falha corrigida e evita um relatório composto apenas pelos resultados favoráveis.
Para cada execução, registre entrada de referência, resultado esperado, resultado observado, condição de aprovação e links para as evidências. Uma recusa pode ser o resultado correto: por exemplo, quando o roteiro pede acesso a um arquivo não autorizado. Descreva essa expectativa antes de testar para que uma mensagem de erro não seja interpretada posteriormente conforme a conveniência.
Inclua cenários que cruzem fronteiras de acesso. Teste com um usuário autorizado e outro perfil que não deveria acessar o mesmo documento. Faça isso em ambiente controlado, com material sintético e permissões conhecidas. Não use documentos reais de outro departamento apenas para demonstrar que uma barreira funciona.
Se o fluxo produzir resumos, guarde também a referência exata da entrada e os critérios de avaliação do conteúdo. A autorização pode funcionar e o resumo omitir uma ressalva. Para detalhar essa parte, consulte o guia sobre omissão de ressalvas em resumos de IA. No dossiê, mantenha o resultado da análise de conteúdo separado do teste de acesso.
Quando um teste não puder ser executado, marque como não executado e explique a causa. Falta de acesso ao relatório, indisponibilidade do ambiente e requisito ainda indefinido são limitações diferentes. A pessoa que decide o aceite precisa enxergar essas lacunas e avaliar se impedem a liberação.
Exemplo: distribuidora em Ribeirão Preto
Imagine uma distribuidora fictícia de Ribeirão Preto que prepara respostas internas a partir de manuais armazenados no Drive. A aplicação usa IA para sugerir um resumo, e o atendente revisa a resposta. A equipe quer homologar o acesso aos documentos escolhidos e a preservação de avisos sobre condições de armazenamento.
O responsável cria dois manuais sintéticos: um selecionado para a aplicação e outro fora do conjunto autorizado. O primeiro contém um aviso deliberado que deve permanecer no resumo. A ficha registra o perfil de teste, a versão da aplicação e as permissões usadas. Os nomes dos arquivos indicam claramente que não são instruções reais de operação.
O caso HOM-01 verifica a leitura do manual selecionado. HOM-02 tenta consultar o documento fora do conjunto autorizado e espera uma recusa. HOM-03 avalia se o aviso permanece na resposta. Cada tentativa recebe um identificador e aponta para a saída correspondente. A equipe consegue avaliar acesso e conteúdo sem fundir os resultados.
Se a consulta for recusada como esperado, o relatório registra o bloqueio e a mensagem exibida. Se o resumo omitir o aviso, HOM-03 reprova mesmo que HOM-01 tenha passado. A decisão pode liberar apenas um piloto limitado depois da correção e de uma nova execução. O dossiê preserva a falha inicial e a evidência da correção, sem atribuir ganhos de produtividade que não foram medidos.
Organize o manifesto e a decisão de aceite
O manifesto é um índice dos arquivos do pacote. Inclua nome, finalidade, caso e execução relacionados, autor ou origem, horário de coleta e nível de acesso. Um resumo criptográfico, chamado hash, pode ajudar a detectar se o conteúdo de um arquivo mudou. Ele não prova sozinho a autoria nem a veracidade do material.
Separe os originais protegidos das cópias preparadas para circulação. Remova tokens, senhas e dados pessoais desnecessários das cópias de revisão. Documente a edição realizada para que um campo ocultado não pareça ausente na evidência original. As políticas de OAuth do Google orientam o tratamento seguro das credenciais e dos tokens; eles não devem ser incorporados ao relatório.
Teste o acesso ao pacote com o perfil de quem fará a revisão. Um índice completo com links inacessíveis interrompe a auditoria da mesma forma que um arquivo ausente. Defina um responsável pela guarda e uma política interna de retenção adequada aos documentos. Não presuma que o prazo de retenção de um log do serviço será o mesmo exigido para o seu dossiê.
A decisão de aceite deve indicar requisitos aprovados, reprovados e não avaliados, além das ressalvas e do responsável pela decisão. Vincule cada conclusão às execuções pertinentes. Mudanças posteriores de versão, permissões ou percurso de dados exigem avaliar quais testes precisam ser repetidos. O pacote anterior continua representando o ambiente em que foi produzido.
Erros comuns
- Guardar só o resultado final: preserve as tentativas anteriores e explique as correções.
- Usar conta administrativa em todos os testes: inclua os perfis que realmente executarão o processo.
- Tratar log como prova de qualidade: avalie separadamente se a resposta da IA atende ao requisito.
- Expor credenciais nas capturas: prepare cópias de revisão sem segredos e registre as ocultações.
- Assinar aceite com lacunas invisíveis: identifique cenários não executados e seu impacto.
Perguntas frequentes
Uma captura de tela basta para homologar?
Ela pode apoiar um teste simples, mas precisa de contexto: requisito, ambiente, entrada e resultado esperado. Para fluxos com acesso a dados e processamento por IA, combine materiais que permitam seguir cada etapa relevante.
Preciso guardar todos os documentos reais usados?
Defina o que é necessário para demonstrar o teste e prefira material sintético quando possível. Se houver conteúdo real indispensável, limite acesso e circulação conforme as regras da empresa. Não copie dados por conveniência para um pacote distribuído amplamente.
Um relatório sem eventos significa que nada aconteceu?
Não necessariamente. Confirme o serviço consultado, a configuração de coleta, o intervalo e as permissões de quem consulta. Registre a limitação se não for possível obter a evidência adequada.
Quando o pacote deve ser atualizado?
Quando houver mudança que afete os requisitos ou as condições testadas. Compare a nova versão com a ficha anterior, escolha os testes pertinentes e produza outro pacote identificado, mantendo o histórico do aceite.
