A Google ensina procedimento governamental ao Gemini. A questão de design é onde o rascunho vira decisão

Um estatuto não é um prompt. Ele tem definições em uma seção que mudam o significado de uma palavra em outra, exceções que sobrepõem a regra geral, datas de vigência e orientações de agência que interpretam o texto de forma diferente do texto literal. Trabalho de governo é aplicar tudo isso, caso a caso, e deixar um registro que explica por quê.

Esse é o problema que a Google se propôs a empacotar em 20 de outubro com Gemini for government services, anunciado por Thomas Kurian, CEO do Google Cloud, e disponível em preview.

Como a Google estruturou

A oferta tem cinco partes:

• Skills para trabalho de governo: instruções e contexto reutilizáveis escritos por especialistas de domínio, cada um aplicando os estatutos, regulamentos e orientações de agência que regem uma tarefa.
• Conectores para sistemas de agência: gestão de casos, ERP, RH, ferramentas de colaboração e fontes de dados federais como Federal Register, regulations.gov e eCFR, consultadas no local sem migrar dados.
• Agentes parceiros de fornecedores de software do setor público, como os agentes de descoberta e tarja de FOIA da SZNS Solutions (o FOIA é o equivalente nos EUA à Lei de Acesso à Informação brasileira, Lei 12.527/2011).
• Um plano de controle governado que aplica políticas entre agentes, com VPC Service Controls, chaves de criptografia gerenciadas pelo cliente e Assured Workloads, incluindo um limite de dados FedRAMP High.
• Saídas fundamentadas com citações a documentos de origem.

O acesso segue as permissões baseadas em função e em nível de registro que as agências já têm. A Google diz que dados e saídas de agências não são usados para treinar seus modelos de fundação sem permissão. O estado do Missouri e o Departamento de Saúde e Serviços Humanos dos EUA são citados como parceiros da Google na validação das capacidades.

Rascunho, proposta ou decisão

A forma mais útil de ler o anúncio é classificar os workflows de exemplo pelo que a saída do agente realmente é. As próprias descrições da Google já traçam a linha na maioria dos casos.

Rascunhos de pesquisa. A pesquisa de políticas e regulatória retorna respostas do CFR, do Federal Register, de códigos administrativos estaduais e de manuais internos, com citações de página e parágrafo, incluindo qual regra prevalece quando regras federais e estaduais se aplicam ao mesmo tempo. Essa última parte é interpretação jurídica. Uma citação permite que um revisor confira a fonte; ela não torna a conclusão correta. A saída é um rascunho para um analista ou para o jurídico.

Propostas que precisam de confirmação. A descoberta de FOIA reúne registros pertinentes ao pedido em um conjunto de revisão para o responsável por registros e o jurídico. A tarja propõe tarjas rotuladas por isenção legal, e exporta cópias tarjadas e um log de isenções somente depois que um revisor confirma. Aqui o agente prepara e uma pessoa confirma, que é o desenho certo. O risco é o volume: quando um agente propõe centenas de tarjas, a confirmação pode virar um clique. Já argumentamos que um human-in-the-loop só é controle se a pessoa puder contestar a IA; agrupar achados para revisão em lotes, como a Google descreve, ajuda, mas a capacidade de revisão precisa ser planejada.

Insumos para decisões. A avaliação de propostas de fornecedores verifica as propostas contra os requisitos do RFP, o FAR e rubricas, e dá aos agentes de contratação “uma base documentada para cada decisão de adjudicação”. Auditorias de subvenções sinalizam custos não permitidos contra o 2 CFR 200 com citações linha a linha. Essas saídas alimentam decisões que carregam responsabilidade legal. O agente de contratação decide; a análise do agente vira parte do processo e deve ser preservada como tal.

Decisões que o agente não deve tomar. A Google não afirma que o sistema toma decisões finais de elegibilidade, enforcement ou adjudicação, e empresas enterprise que constroem sobre ele também não devem. Essa fronteira pertence ao desenho, registrada por workflow, e não a um disclaimer.

O que definir antes de um piloto

Quem é responsável por cada skill. Um skill que codifica como um estatuto se aplica é um procedimento. Quando o regulamento muda, alguém precisa atualizá-lo, testá-lo e registrar a versão em vigor para cada caso. Trate skills como documentos de orientação controlados, com um responsável, uma data de vigência e um ciclo de revisão.

Qual versão respondeu. Se um cidadão ou um auditor contestar uma decisão meses depois, a agência precisa saber qual versão do skill, quais fontes e qual modelo produziram a análise por trás dela.

Onde mora a autorização. Conectores que consultam sistemas no local, sob permissões existentes, mantêm a autoridade onde ela já está, no sistema de registro. Essa é a parte mais forte do desenho, e a razão pela qual a arquitetura pode funcionar: o agente raciocina, o sistema que é dono da transação autoriza.

Times do setor privado em setores regulados devem acompanhar este preview de perto. Troque “estatuto” por “SOP” ou “política de crédito” e a arquitetura é a mesma, e as perguntas também.