A adoção de IA corporativa exige um harness para organizar modelos, ferramentas e permissões. Essa camada de arquitetura, como o Agent Development Kit, separa a lógica de negócio do modelo probabilístico. Isso permite a substituição de modelos, controle de custos e roteamento de tarefas conforme a complexidade e sensibilidade.
A arquitetura no Google Cloud integra modelos Gemma e serviços como Gemini Enterprise Agent Platform. A execução ocorre no Agent Runtime, Cloud Run ou GKE, conforme a necessidade de controle e escalabilidade. O foco reside na segurança via infraestrutura, avaliação contínua e integração controlada com ferramentas e dados corporativos.
Harness open-source, modelos locais e Google Cloud: um guia para arquiteturas corporativas de IA
A adoção corporativa de inteligência artificial amadureceu além da simples escolha de um modelo. Em uma prova de conceito, pode ser suficiente enviar uma instrução a um LLM e apresentar a resposta. Em produção, a solução precisa identificar usuários, consultar dados, utilizar ferramentas, aplicar permissões, controlar custos, tratar falhas e registrar o que foi executado.
O modelo não deveria assumir todas essas responsabilidades. Ele é um componente probabilístico inserido em uma aplicação maior.
O harness de IA é a camada que organiza essa aplicação. Ele controla como o modelo recebe contexto, quais ferramentas pode utilizar, quando uma ação precisa de aprovação e como a qualidade será acompanhada. Quando essa camada é construída sobre um framework aberto, a empresa preserva maior controle sobre sua arquitetura e reduz o acoplamento entre a lógica do produto e um modelo específico.
No ecossistema do Google Cloud, essa abordagem pode combinar o Agent Development Kit, modelos Gemma, a Gemini Enterprise Agent Platform e ambientes de execução como Agent Runtime, Cloud Run e GKE.
1. O que é um harness open-source
Neste contexto, harness não é o nome de um produto. É um padrão de arquitetura que envolve o modelo com controles de aplicação.
Uma implementação normalmente reúne:
- Orquestração de etapas e agentes;
- Seleção do modelo;
- Preparação do contexto;
- Estado e memória;
- Integração com ferramentas;
- Validação de entradas e saídas;
- Autorização de ações;
- Tratamento de falhas;
- Observabilidade;
- Avaliação.
O Agent Development Kit, ou ADK, é o framework open-source do Google para construir essa camada. Ele permite implementar agentes individuais, sistemas com múltiplos agentes e workflows nos quais etapas determinísticas convivem com decisões realizadas por modelos.
Essa combinação é importante porque nem todas as partes de um processo devem depender de inferência probabilística.
Em um fluxo de análise e aprovação, por exemplo, o modelo pode interpretar um documento e produzir uma recomendação. A aplicação, no entanto, deve continuar responsável por validar campos, consultar limites, verificar permissões e solicitar aprovação antes de qualquer alteração.
O harness transforma o modelo em uma dependência controlada da aplicação, em vez de transformar a aplicação em uma sequência de prompts.
2. Por que separar o harness do modelo
Quando a lógica de negócio fica concentrada em prompts específicos para um único modelo, qualquer mudança pode exigir uma revisão ampla da solução.
A separação permite que a aplicação mantenha contratos estáveis enquanto os modelos evoluem.
O harness pode definir, por exemplo, que uma etapa deverá receber um documento e devolver uma estrutura JSON com determinados campos. O modelo responsável por essa tarefa pode ser substituído, desde que a nova opção cumpra o mesmo contrato e seja aprovada nos testes.
Essa arquitetura também permite usar modelos diferentes dentro do mesmo processo.
Um modelo local pode realizar classificação e extração. Um modelo gerenciado pode ser utilizado quando a tarefa exige análise mais complexa. Regras convencionais podem validar formatos, limites e permissões.
O roteamento pode considerar:
- Sensibilidade dos dados;
- Complexidade da solicitação;
- Latência aceitável;
- Custo;
- Volume;
- Capacidade de raciocínio;
- Suporte a ferramentas;
- Requisitos multimodais.
A empresa deixa de escolher um único modelo para toda a solução e passa a escolher o componente mais adequado para cada tarefa.
Essa separação também melhora a capacidade de teste. O comportamento de cada modelo pode ser comparado utilizando os mesmos dados, ferramentas e critérios de avaliação.
3. Onde os modelos locais fazem sentido
A família Gemma reúne modelos abertos do Google que podem ser executados em hardware próprio, dispositivos ou serviços hospedados.
O fato de o modelo poder ser executado localmente não significa que essa seja sempre a melhor arquitetura. A decisão deve considerar o workload.
Modelos locais são especialmente úteis em tarefas com escopo limitado e volume previsível, como:
- Classificação de documentos;
- Extração de campos;
- Identificação de intenção;
- Roteamento de solicitações;
- Normalização de conteúdo;
- Filtragem de dados sensíveis;
- Function calling restrito;
- Operação offline.
Um modelo local também pode atuar como primeira camada de processamento. Ele pode identificar informações sensíveis, reduzir o contexto ou decidir se a tarefa exige um modelo de maior capacidade.
Entretanto, a execução local transfere responsabilidades para a empresa. Será necessário administrar o runtime de inferência, as versões dos modelos, a infraestrutura, a segurança, o monitoramento e a capacidade disponível.
O custo também não deve ser analisado apenas como ausência de cobrança por token. Uma implantação própria envolve GPU, memória, armazenamento, energia, administração, disponibilidade e capacidade ociosa.
Para volumes pequenos ou irregulares, um modelo gerenciado pode ter custo total inferior. Para cargas recorrentes, específicas e bem conhecidas, o modelo local pode oferecer maior previsibilidade.
4. Arquitetura de referência no Google Cloud
Uma arquitetura híbrida pode ser organizada em quatro camadas.
Aplicação, API ou interface
│
▼
Harness desenvolvido com ADK
│
┌──────┴─────────┐
▼ ▼
Modelo Gemma Modelo gerenciado
local ou próprio na Agent Platform
│ │
└──────┬─────────┘
▼
Ferramentas, APIs e dados corporativos
│
▼
IAM, segurança, auditoria e observabilidade
O ADK mantém a lógica do agente e define quais modelos e ferramentas podem participar de cada fluxo.
A Gemini Enterprise Agent Platform fornece a camada gerenciada para construção, execução, governança e otimização de agentes. Ela pode ser utilizada para hospedar a aplicação no Agent Runtime, consumir modelos gerenciados e integrar serviços de avaliação e observabilidade.
Os modelos Gemma podem ser executados separadamente em Cloud Run ou GKE e expostos ao harness por meio de um endpoint autenticado.
A aplicação não precisa enviar todas as solicitações ao mesmo ambiente. Uma política de roteamento pode manter localmente tarefas simples ou sensíveis e utilizar modelos gerenciados apenas quando a capacidade adicional for necessária.
Exemplo de fluxo:
- O modelo local classifica a solicitação;
- O harness verifica sensibilidade, risco e complexidade;
- Casos simples permanecem no modelo local;
- Casos complexos são encaminhados a um modelo gerenciado;
- A resposta é validada;
- A ação é executada somente se estiver autorizada;
- O resultado e a trajetória são registrados.
O ganho dessa arquitetura não é apenas reduzir custos. Ela permite estabelecer controles diferentes para tarefas com características distintas.
5. Agent Runtime, Cloud Run ou GKE
A escolha do ambiente de execução depende do quanto a equipe deseja administrar.
Agent Runtime
O Agent Runtime é o ambiente gerenciado da Gemini Enterprise Agent Platform para implantar e escalar aplicações agentivas.
Ele é apropriado quando o projeto pretende concentrar a equipe na lógica do agente, utilizando uma infraestrutura opinativa e integrada aos recursos da plataforma.
Esse modelo reduz o esforço relacionado a deploy, escalabilidade e operação do agente, embora a empresa ainda precise projetar ferramentas, permissões, testes e políticas.
Cloud Run
O Cloud Run oferece suporte a inferência com GPU e possui documentação específica para executar agentes com Gemma e vLLM.
É uma opção adequada para aplicações containerizadas, topologias simples e tráfego variável. A equipe administra o container e a configuração do serviço, mas não precisa operar um cluster Kubernetes.
Os principais pontos de atenção são tempo de inicialização, carregamento dos pesos, concorrência, memória de GPU e número mínimo de instâncias.
GKE
O Google Kubernetes Engine oferece maior controle sobre hardware, rede, armazenamento e escalabilidade.
A documentação do Google apresenta uma arquitetura para executar Gemma no GKE com vLLM. O vLLM utiliza técnicas como continuous batching e PagedAttention para melhorar o uso de memória e a capacidade de atendimento.
GKE tende a ser mais adequado quando o projeto possui:
- Múltiplos modelos;
- Inferência contínua;
- Alta concorrência;
- Serving distribuído;
- Diferentes pools de GPU;
- Requisitos específicos de rede;
- Necessidade de maior controle operacional.
A flexibilidade vem acompanhada da responsabilidade de administrar cluster, nodes, drivers, imagens, autoscaling, atualizações e observabilidade.
| Ambiente | Uso mais adequado |
|---|---|
| Agent Runtime | Agentes gerenciados e integrados à plataforma |
| Cloud Run | Serviço containerizado com tráfego variável |
| GKE | Infraestrutura de inferência complexa ou contínua |
| Ambiente próprio | Restrições locais, offline ou soberania específica |
6. Integração com ferramentas e dados
O risco de uma aplicação agentiva não está apenas na resposta textual. Ele aumenta quando o agente recebe capacidade para consultar ou alterar sistemas.
As ferramentas devem representar operações de negócio delimitadas.
Uma função genérica como:
executar_sql(query)
oferece ao agente uma superfície de atuação desnecessariamente ampla.
Uma função específica é mais controlável:
consultar_status_pedido(id_pedido)
A mesma lógica se aplica a operações de escrita. Em vez de permitir alterações genéricas, a aplicação pode oferecer funções como:
solicitar_cancelamento(
id_pedido,
motivo,
usuario_solicitante
)
Cada ferramenta deve definir entradas, saídas, permissões, timeout, idempotência, tratamento de erros e registros de auditoria.
O harness também deve controlar quais ferramentas são apresentadas a cada agente. Um agente de consulta não precisa receber funções de exclusão ou alteração.
A integração pode ser realizada por APIs convencionais ou por protocolos como MCP, desde que o protocolo não seja confundido com uma política de segurança. O MCP padroniza a interface; a autorização continua dependendo da arquitetura.
O acesso a dados deve seguir o mesmo princípio. O agente deve receber apenas o contexto necessário para a tarefa, preferencialmente por meio de consultas controladas e com rastreabilidade.
7. Segurança, avaliação e operação
Prompts não substituem controles de segurança.
Uma instrução como “não divulgue dados confidenciais” é útil para orientar o comportamento, mas não deve ser a barreira responsável por proteger as informações.
O controle precisa existir na infraestrutura:
- IAM e identidades específicas;
- Princípio do menor privilégio;
- Segregação entre ambientes;
- Gestão de segredos;
- Validação de parâmetros;
- Aprovação para ações sensíveis;
- Registro de ferramentas utilizadas;
- Políticas de retenção de contexto;
- Monitoramento de custos e falhas.
O Model Armor pode inspecionar prompts e respostas para identificar riscos como prompt injection, jailbreak e exposição de dados sensíveis. Ele funciona como uma camada adicional, não como substituto para autorização e isolamento.
A observabilidade precisa acompanhar mais do que latência e erros. A Gemini Enterprise Agent Platform oferece recursos de observabilidade para acompanhar sessões, chamadas, consumo, ferramentas e métricas de qualidade.
A avaliação também deve considerar a trajetória.
Uma resposta pode estar correta, mas ter sido produzida depois de acessar uma ferramenta indevida ou ignorar uma aprovação. Por isso, os testes precisam avaliar:
- Resultado final;
- Ferramentas selecionadas;
- Parâmetros enviados;
- Ordem das etapas;
- Respeito às políticas;
- Custo;
- Latência;
- Recuperação de falhas.
A plataforma também oferece monitoramento contínuo de qualidade, permitindo identificar degradação provocada por mudanças no modelo, nos dados ou no comportamento dos usuários.
8. Como iniciar um projeto
Um projeto dessa natureza deve começar com um caso de uso delimitado, e não com a decisão de instalar um modelo.
A primeira etapa consiste em documentar:
- Processo atual;
- Resultado esperado;
- Dados envolvidos;
- Sistemas;
- Volume;
- Latência;
- Requisitos de segurança;
- Ações permitidas;
- Critérios de qualidade.
Depois, as tarefas devem ser classificadas entre determinísticas e probabilísticas. Nem toda automação precisa utilizar IA generativa, e nem toda decisão deve ser delegada a um agente.
O próximo passo é comparar modelos utilizando dados reais anonimizados. Gemma e modelos gerenciados devem ser avaliados com a mesma rubrica, observando qualidade, tool calling, latência, custo e comportamento diante de exceções.
Somente depois do benchmark deve ser escolhido o runtime.
Um roteiro objetivo pode seguir cinco entregas:
- Discovery técnico: processo, dados, riscos e requisitos;
- Benchmark: comparação de modelos e configurações;
- Harness: agentes, ferramentas, workflows e políticas;
- Produção: Agent Runtime, Cloud Run, GKE ou ambiente próprio;
- Operação: segurança, avaliação, observabilidade e otimização.
Como parceira Google Cloud, a REVIIV atua na estruturação e no desenvolvimento de projetos que combinam agentes, modelos locais e infraestrutura Google Cloud.
Esse trabalho pode envolver discovery, desenvolvimento com ADK, benchmark de Gemma e modelos gerenciados, implantação no Agent Runtime, Cloud Run ou GKE, integração com sistemas corporativos e implementação de controles de segurança e avaliação.
A função do parceiro técnico não deve ser aplicar todos os componentes disponíveis. Deve ser escolher uma arquitetura proporcional ao problema.
Para alguns processos, um agente gerenciado será a opção mais eficiente. Para outros, um modelo local oferecerá maior controle. Em muitos projetos, a composição híbrida será mais adequada do que qualquer alternativa isolada.
Conclusão
Um harness open-source permite que a lógica da aplicação permaneça separada do modelo e do ambiente de execução. Essa separação facilita testes, roteamento, evolução tecnológica e controle operacional.
Os modelos Gemma ampliam as opções de implantação local ou autogerenciada. A Gemini Enterprise Agent Platform oferece recursos gerenciados para construir, operar e avaliar agentes. Cloud Run e GKE atendem diferentes níveis de controle e complexidade de infraestrutura.
A decisão deve considerar o sistema completo: dados, ferramentas, permissões, qualidade, custo e operação.
O modelo é uma parte da arquitetura. O valor do projeto depende de como essa capacidade é integrada a um processo real, com limites definidos e resultados mensuráveis.
A REVIIV é parceira oficial da Google Cloud e pode apoiar de ponta-a-ponta desde o provisionamento de recursos, ao desenvolvimento, implantação e sustentação com utilização de profissionais certificados.
FAQ
O que é um harness open-source de IA?
É a camada de software que organiza modelos, ferramentas, contexto, memória, workflows, políticas e avaliações. O ADK é o framework open-source do Google para esse tipo de desenvolvimento.
É possível utilizar modelos Gemma localmente?
Sim. Gemma pode ser executado em hardware próprio, dispositivos ou infraestrutura hospedada, conforme o tamanho do modelo e os recursos disponíveis.
Quando utilizar Cloud Run ou GKE?
Cloud Run é mais adequado para serviços containerizados com menor complexidade operacional e tráfego variável. GKE oferece maior controle para múltiplos modelos, alta concorrência e serving distribuído.
Modelos locais são sempre mais baratos?
Não. O custo precisa incluir hardware, GPU, capacidade ociosa, energia, manutenção, segurança e equipe operacional.
