Governança de IA não é governança de TI, saiba o que é Harness e como melhorá-lo.

Resumo

• Harness é tudo o que cerca o modelo para o agente acertar: guias antes de agir e sensores depois. Melhorar um harness exige saber onde ele falhou, e isso depende de registro, não de prompt.
• Governança de IA não é governança de TI. O sistema não é determinístico, a supervisão não termina no release, o registro precisa acompanhar toda a vida do sistema e o humano precisa poder reverter o que a máquina fez.
• GIRO é a nossa sigla para quatro camadas: governança, interpretabilidade, rastreabilidade e observabilidade. A sigla é nossa. Os conceitos vêm de uma literatura internacional que, na nossa percepção, o Brasil ainda pratica pouco.
• O GIRO resolve problemas que vão além de guardar decisões: troca de modelo, custo real, atenção humana, agentes que divergem, rotatividade de equipe, auditoria, incidentes e a evolução do próprio método.
• Ele tem limites, e uma parte dele já está disponível para qualquer pessoa no Blueprint, que é aberto.

Por que todo mundo fala de harness agora

No primeiro semestre de 2026, duas publicações deram nome a algo que muita equipe já fazia no improviso. A OpenAI contou como um time construiu um produto interno com o Codex escrevendo todo o código, e resumiu a divisão de papéis em quatro palavras: "Humans steer. Agents execute." (OpenAI ↗ (abre em outra aba)). Pouco depois, Birgitta Böckeler, da Thoughtworks, publicou no site de Martin Fowler uma definição curta: Agent = Model + Harness (Böckeler ↗ (abre em outra aba)). O modelo é o que alugamos. O harness é o resto, e é o que construímos.

Existe também um motivo de caixa. A Gartner prevê que mais de 40% dos projetos de IA agêntica serão cancelados até o fim de 2027, por "custos crescentes, valor de negócio pouco claro ou controles de risco inadequados" (Gartner ↗ (abre em outra aba)). Nenhuma das três causas é "o modelo não era bom o bastante". São problemas de custo, de valor e de risco, e na minha leitura, são problemas de governança.

O que é um harness, descomplicado

Pense no agente como um profissional muito rápido, que não lembra de ontem e que faz exatamente o que o contexto sugere. O harness é o ambiente de trabalho que a gente monta ao redor dele. Böckeler divide esse ambiente em duas partes:

• Guias (feedforward): orientam o agente antes de agir. Instruções, convenções de arquitetura, exemplos, a estrutura do repositório.
• Sensores (feedback): observam o que o agente fez e permitem que ele se corrija. Podem ser computacionais (testes, linters, verificação de tipos: rápidos e determinísticos) ou inferenciais (revisão por outra IA: mais lentos, mais caros e menos determinísticos, mas capazes de julgamento semântico).

O papel humano, segundo ela, é conduzir: sempre que um problema se repete, o humano melhora um guia ou um sensor. Böckeler também registra um limite que faz muito sentido: o comportamento do sistema é a categoria mais difícil de colocar sob harness.

O relato da OpenAI vai na mesma direção com detalhes práticos. Quando o agente falhava, a correção era dar a ele a capacidade que faltava, e não "tentar com mais força". O arquivo de instruções principal tinha cerca de cem linhas e funcionava como um índice. O conhecimento real ficava em documentos versionados no repositório, porque, nas palavras do relato, "o que o agente não consegue ver no repositório, na prática, não existe". Um arquivo gigante de instruções ocupava o contexto e envelhecia rápido, o que hoje em dia já é uma deficiência conhecida.

Tudo isso é engenharia boa. Mas repare no que está faltando: nenhuma dessas práticas diz como você descobre qual guia falhou, qual decisão levou ao problema e quanto custou chegar até ali. Sem isso, melhorar o harness acaba virando só um palpite, o famoso "confia".

Governança de IA não é governança de TI

A governança de TI nasceu para sistemas previsíveis. Um artigo da IEEE Computer Society resume bem: a governança convencional mirava sistemas determinísticos, e os frameworks construídos em torno de previsibilidade e linearidade se mostram inadequados para a IA (IEEE Computer Society ↗ (abre em outra aba)). Na prática, a diferença aparece em cinco pontos.

1. O sistema não é determinístico. O NIST dedica um apêndice do seu framework de gestão de risco de IA a listar riscos que são novos ou maiores do que no software tradicional, entre eles a escala (sistemas com bilhões de pontos de decisão) e a dificuldade de entender o que o sistema faz (NIST AI RMF 1.0 ↗ (abre em outra aba)). Testar uma vez e liberar deixa de ser suficiente.
2. A supervisão não termina no release. Para a IBM, governança de IA "não é só garantir conformidade uma única vez", porque modelos mudam e derivam (IBM ↗ (abre em outra aba)). Software tradicional muda quando alguém muda o código. Sistemas com IA podem mudar de comportamento sem que ninguém toque em nada.
3. O registro precisa durar a vida inteira do sistema. O AI Act europeu exige que sistemas de alto risco permitam tecnicamente o registro automático de eventos (logs) "ao longo da vida do sistema", para dar rastreabilidade (AI Act, art. 12 ↗ (abre em outra aba)).
4. O humano precisa poder reverter. O artigo 14 do mesmo regulamento pede que quem supervisiona entenda as capacidades e os limites do sistema, desconfie da própria tendência de confiar demais na saída da máquina (o viés de automação) e possa ignorá-la, revertê-la ou interromper o sistema (AI Act, art. 14 ↗ (abre em outra aba)).
5. A decisão foi tomada por alguém que não lembra. Este ponto é nosso, e não de uma fonte. Na governança de TI tradicional, quando surge a pergunta "por que o sistema faz isso?", existe uma pessoa a quem perguntar. Quando quem decidiu foi um agente, a resposta não está na memória de ninguém, a menos que o processo a tenha gravado. Gosto de dizer que "o registro deixa de ser burocracia e passa a ser a única memória que existe".

Há ainda uma distinção que a conversa sobre governança de IA costuma esquecer. Existe governar a IA que você entrega (o foco de NIST, União Europeia e IBM) e existe governar a IA que constrói o seu software. O GIRO é, em essência, essa segunda, mas também funciona na primeira, porque o rastro de quem construiu vira o histórico de quem opera.

Como chegamos ao GIRO

Chegamos por uma necessidade simples. Ao desenvolver projetos, nossos e de terceiros, não tínhamos como verificar quando uma decisão tinha sido tomada, nem por quê.

A primeira ideia foi usar uma ferramenta de observabilidade. E então, depois de pesquisar e estudar um pouco mais a fundo, cheguei ao Langfuse, uma plataforma aberta que pode ser hospedada na própria infraestrutura. Depois de configurá-lo e rastrear tudo o que os agentes faziam, gostei muito do resultado, e logo ficou claro que carregar essas informações era um diferencial. E isso porque elas tornavam documentável a evolução do projeto, o caminho que o agente percorre dentro dele e a evolução do nosso próprio desenvolvimento. Ali nasceu o O.

O problema seguinte era outro: os agentes não conseguiam entender uns aos outros. Quando um agia de um jeito e outro agia de forma diferente, ninguém sabia por quê. Fora que isso também leva à um outro problema, que é os agentes "tropeçarem no pé um do outro". Então, para resolver, construímos o Lore, que grava o registro das atividades dos agentes em documentos e os indexa para que os próprios agentes, e as pessoas, consultem. Já tínhamos a ideia, e a leitura sobre o ai-memory ↗ (abre em outra aba), um servidor de memória de longo prazo para agentes de código, nos ajudou a desenhá-la: o Lore é uma evolução pensada para as nossas necessidades e cloud-only. Queríamos um segundo cérebro de verdade, e não algo que pense por nós. Quem pensa e decide continua sendo gente.

Havia uma razão mais antiga para a rastreabilidade e a interpretabilidade, que já existia antes do Lore. Acontece que parte do nosso trabalho se dirige ao mercado regulado brasileiro. A LGPD garante ao titular o direito de pedir a revisão de decisões tomadas unicamente com base em tratamento automatizado de dados pessoais, e o controlador deve fornecer, quando solicitado, informações claras sobre os critérios e procedimentos usados (art. 20 e § 1º). Logo, ferramentas de rastreabilidade são cruciais para mostrar esse controle, e ela precisa ser intrínseca ao método, não um anexo.

Ao pesquisar a literatura internacional, vimos que essas práticas já são empurradas pela regulação europeia. Já no Brasil, na minha percepção, ainda não são uma prática comum entre empresas de tecnologia ou AI First. Não encontramos dados brasileiros sobre isso, então leia como convicção, não como estatística.

O G veio depois e é, de certa forma, o que amarra os outros. Falamos dele abaixo.

As quatro camadas

A sigla é nossa, e o sentido de giro não é só a abreviação, também significa que é a peça que gira o método, o ciclo que se repete. É o que queremos que aconteça, porque cada projeto devolve pra gente o que aprendeu.

G, de governança

Governança, para nós, tem duas metades.

A primeira é a decisão humana. O agente não avança uma etapa sozinho e não se autoaprova. As decisões, das mais simples às mais caras de desfazer, ficam registradas, e as caras sempre passam por uma pessoa.

A segunda é o padrão. Governança de IA, no nosso uso, é a parte de harness: manter todos os projetos sob o mesmo critério de engenharia de software e conseguir coordenar equipes, squads e agentes. Lideranças e tech leads conseguem ensinar a quem entra como desenvolvemos, por que o método é assim, por que ele consolida práticas já difundidas lá fora e como cada pessoa pode ajudar a evoluí-lo.

O limite: um padrão que ninguém segue é decoração. A governança vale o quanto a equipe a pratica, e é por isso que ela precisa ser ensinável.

I, de interpretabilidade

Toda decisão do agente vem com uma justificativa legível.

Entretanto, não leia isso como interpretabilidade no sentido da pesquisa sobre o interior das redes neurais.

O NIST distingue três pilares que começam com a transparência, que responde "o que aconteceu"; a explicabilidade, respondendo "como" a decisão foi tomada; e a interpretabilidade, que trata do significado da saída no contexto em que ela é usada — basicamente o "porquê". O nosso I está nessa terceira pergunta, no nível do processo: por que o agente escolheu esta opção em vez de outra, dentro deste projeto.

O limite: a justificativa que o agente escreve pode não ser a causa real. Em um estudo da Anthropic, modelos de raciocínio receberam dicas para as respostas de uma avaliação e mencionaram a dica em média em 25% das vezes (Claude 3.7 Sonnet) e 39% (DeepSeek R1). Em um cenário de reward hacking, os modelos exploraram a dica em mais de 99% dos casos e admitiram isso em menos de 2% na maioria dos ambientes (Anthropic ↗ (abre em outra aba)). Por isso tratamos a justificativa como hipótese a ser conferida, e não como prova. Ela é ancorada em fatos que o agente não escreve sozinho, os documentos, a fonte e o registro do que ele de fato fez, que vem da observabilidade.

R, de rastreabilidade

Cada decisão está ligada a um documento, a um autor e a uma data. A pergunta "por que o sistema faz isso?" passa a ter resposta que não depende da memória de ninguém.

Um cuidado de projeto: registro que custa mais do que o trabalho acaba desligado. Queríamos registrar decisões caras, decisões simples e a evolução das atividades de forma automática, sem consumir uma quantidade absurda de tokens só para documentar a construção. Esse foi um dos requisitos que moldaram o Lore.

O limite: rastro não é verdade. Um registro mostra o que foi decidido e por quem, e não garante que a decisão foi boa.

O, de observabilidade

Custo e ações de cada agente, etapa e artefato são medidos. No nosso caso, gotamos de usar o Langfuse para isso, que guarda as chamadas ao modelo com prompt, resposta, consumo de tokens, latência e execuções de ferramentas (Langfuse ↗ (abre em outra aba)).

O limite: observabilidade diz o que aconteceu e quanto custou, e não se estava certo. Ela alimenta o julgamento humano, mas não o substitui.

Como melhorar o seu harness

Cinco movimentos que combinam o que as fontes recomendam com o que aprendemos na prática. Os dois primeiros vêm de OpenAI e Böckeler. Os outros são conclusões nossas.

1. Trate falha recorrente como defeito do harness, não do agente. Se o mesmo erro aparece duas vezes, falta um guia ou um sensor. Adicione a capacidade que falta.
2. Mantenha o arquivo de entrada curto. Use-o como índice e coloque o conhecimento em documentos versionados no repositório.
3. Prefira sensores computacionais e use os inferenciais com parcimônia. Testes e verificações determinísticas são rápidos e baratos. Deixe a revisão por IA para o que só ela alcança.
4. Meça onde o agente gasta e onde ele trava. Sem isso você não sabe qual guia ou sensor melhorar primeiro. É o O do GIRO a serviço do harness.
5. Registre por que cada regra existe. Todo harness acumula regras, e algumas existem para compensar a fraqueza de um modelo que já foi superado. Se você sabe a razão de cada uma, consegue aposentá-la quando o modelo melhora, em vez de carregar um harness cada vez mais pesado. Harness também tem dívida técnica.

O que o GIRO resolve além de "guardar decisões"

Guardar decisões é o óbvio. Abaixo detalho alguns dos problemas menos óbvios que enxergo quando essa trilha existe:

A troca de modelo que ninguém consegue auditar. Modelos são trocados e aposentados com frequência. Eu acredito que a observabilidade nesses momentos é essencial para garantir consistência e evolução, uma vez que ela registra qual modelo e qual prompt foi usado a cada chamada. E isso somado à rastreabilidade, que liga as decisões a documentos, torna possível reexaminar apenas o que um modelo antigo decidiu, em vez de desconfiar de tudo.

O preço fixo sobre um trabalho que ninguém mediu. Quem vende projeto de escopo fechado construído com agentes precisa saber quanto custou, de verdade, cada etapa. Com custo medido por agente, etapa e artefato, o preço deixa de ser só "feeling". A Gartner coloca o custo crescente entre as causas de cancelamento de projetos de IA agêntica, e medir é a primeira defesa.

A sensação de velocidade. Em um ensaio controlado do METR, 16 desenvolvedores experientes resolveram 246 tarefas reais em repositórios que conheciam. Com IA liberada, levaram 19% mais tempo. Antes, esperavam ser 24% mais rápidos. Depois, ainda acreditavam ter ficado cerca de 20% mais rápidos (METR ↗ (abre em outra aba)). O estudo é de ferramentas do início de 2025 e de um perfil específico de desenvolvedor, então não se generaliza sem cautela. Mas o ensinamento vale: a percepção de produtividade e a medida podem divergir, e só quem mede sabe de que lado está.

A atenção humana como recurso escasso. Na experiência da OpenAI, o limite do time passou a ser o tempo e a atenção das pessoas. Quando as decisões estão classificadas por custo de desfazer, o humano gasta atenção onde ela vale: revisa as caras com cuidado e confere por amostra as simples.

Agentes que divergem sem saber que divergem. Dois agentes que trabalham no mesmo projeto com instruções ou contextos diferentes tomam caminhos diferentes. Sem memória compartilhada, ninguém sabe por quê. Com ela, a divergência vira informação: dá para ver qual contexto levou a qual escolha.

A equipe que muda. O que eu, particularmente, mais olho. Squads recebem e perdem gente, e isso pode acontecer a qualquer momento. Então o que foi decidido e por quê nunca pode morar na cabeça de quem saiu. Quem chega lê a trilha e entende o porquê, e não só o quê. E como na Síntese todo artefato produzido é do cliente, a trilha vai junto com o código: as decisões sobrevivem à troca de equipe também do lado de quem contratou.

A pergunta do comprador, do auditor e do investigador de incidente. No mercado regulado, por exemplo, a pergunta aparece cedo: "como essa decisão foi tomada?". E quando algo dá errado em produção, as perguntas que fazemos são algo do tipo: "qual decisão, de qual agente, com qual contexto introduziu o problema? Se uma instrução maliciosa chegou ao agente, de onde ela veio?". Sem trilha só dá para especular. Com trilha, dá para responder com evidência. Num mercado em que a Gartner estima que apenas cerca de 130 dos milhares de fornecedores que se dizem "agênticos" realmente o são, mostrar o processo vale mais do que declará-lo.

O método que aprende com o próprio histórico. Se cada projeto deixa decisões, custos e pontos em que o agente travou, o seu framework passa a ter histórico, quase como um changelog: dá para ver qual regra surgiu depois de qual falha e qual pode ser aposentada. A DORA, em seu relatório de 2025, afirma que "o papel primário da IA no desenvolvimento de software é o de amplificador" (DORA ↗ (abre em outra aba)): ela amplia a força das organizações que vão bem e as disfunções das que vão mal. Um método que aprende com o próprio histórico decide o que está sendo amplificado.

Como outras organizações enquadram o tema

Nenhuma delas usa a nossa sigla, mas os conceitos se cruzam. De forma resumida:

No campo das ferramentas, o projeto OpenTelemetry mantém convenções abertas para spans, métricas e eventos de IA generativa, o que aponta para um vocabulário comum de observabilidade (repositório ↗ (abre em outra aba)). A ISO/IEC 42001, publicada em 2023, descreve requisitos para estabelecer, implementar, manter e melhorar continuamente um sistema de gestão de IA (ISO ↗ (abre em outra aba)).

O que isso significa no Brasil

A LGPD já dá ao titular o direito de pedir a revisão de decisões tomadas unicamente por tratamento automatizado de dados pessoais, e prevê que a autoridade nacional possa auditar aspectos discriminatórios quando o controlador se recusar a dar informações com base em segredo comercial (Lei 13.709/2018, art. 20 ↗ (abre em outra aba)).

O marco legal da IA, o PL 2338/2023, foi aprovado pelo Senado no fim de 2024 e tramita na Câmara, em comissão especial. A ficha de tramitação mostra a proposição aguardando o parecer do relator (Câmara dos Deputados ↗ (abre em outra aba)). A votação não tem data certa, e as informações de acompanhamento que consultamos indicam que deve ficar para depois das eleições. Não sabemos o texto final. Sabemos que quem começar a registrar agora chega à lei com a trilha pronta, e que quem não começar vai ter que reconstruí-la.

Quer acompanhar essa tramitação? O Olho na Lei ↗ (abre em outra aba), uma ferramenta nossa, reúne em um só lugar os projetos em andamento na Câmara e no Senado, o resultado de cada votação e como cada parlamentar votou, com dados dos portais de dados abertos das duas casas. É um jeito de ver o que está acontecendo sem depender de notícia.

Onde entra o Blueprint

Parte dessa camada já está disponível para qualquer pessoa. O Blueprint é uma ferramenta livre e aberta que conduz uma ideia até o repositório pronto para desenvolver com agentes. Nele, cada decisão é registrada com o motivo, o estado do projeto e o diário ficam em arquivos do próprio repositório, e a memória e a observabilidade podem ser conectadas quando já existem. Ele também diz quando não vale a pena usar uma ferramenta como o Langfuse.

O que o GIRO não faz

• Não garante que a decisão seja boa. Registra, explica e mede. Quem julga continua sendo a pessoa.
• Não torna a justificativa do agente uma prova. Como mostra o estudo da Anthropic, o raciocínio declarado pode não refletir a causa real, e por isso conferimos contra o que foi de fato feito.
• Não é certificação. Adotar o GIRO não equivale a estar em conformidade com o AI Act, com a ISO/IEC 42001 ou com a LGPD. Conformidade é assunto de jurídico e de auditoria.
• Não tem estudo comparativo. Descrevemos prática e raciocínio. Ainda não medimos de forma controlada o efeito do GIRO sobre a qualidade do que é entregue.

Para quem quiser construir junto

O GIRO é uma proposta, e propostas melhoram quando alguém discorda. Se você trabalha com agentes e tem um jeito diferente de resolver alguma destas quatro camadas, queremos ouvir. Um mapeamento do GIRO para a ISO/IEC 42001 e para os requisitos do AI Act, feito por quem entende de conformidade, seria uma contribuição de enorme valor. Para participar, comece pela comunidade da Síntese ↗ (abre em outra aba).

Fontes

• OpenAI, Harness engineering: leveraging Codex in an agent-first world ↗ (abre em outra aba).
• Birgitta Böckeler, Harness engineering ↗ (abre em outra aba), em martinfowler.com.
• Gartner, Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 ↗ (abre em outra aba).
• IEEE Computer Society, Bridging the Governance Gap: AI, Risk, and Enterprise Innovation ↗ (abre em outra aba).
• NIST, AI Risk Management Framework 1.0 (NIST AI 100-1) ↗ (abre em outra aba).
• IBM, What is AI governance ↗ (abre em outra aba).
• União Europeia, AI Act, art. 12 ↗ (abre em outra aba) e art. 14 ↗ (abre em outra aba).
• ISO, ISO/IEC 42001:2023 ↗ (abre em outra aba).
• Anthropic, Reasoning models don't always say what they think ↗ (abre em outra aba) e Our framework for developing safe and trustworthy agents ↗ (abre em outra aba).
• METR, Early 2025 AI experienced open-source developer study ↗ (abre em outra aba).
• DORA, 2025 State of AI-assisted Software Development ↗ (abre em outra aba).
• Langfuse, documentação de observabilidade ↗ (abre em outra aba) e repositório ↗ (abre em outra aba).
• OpenTelemetry, convenções semânticas de GenAI ↗ (abre em outra aba).
• ai-memory, repositório ↗ (abre em outra aba).
• Lei 13.709/2018 (LGPD), art. 20 ↗ (abre em outra aba).
• Câmara dos Deputados, ficha de tramitação do PL 2338/2023 ↗ (abre em outra aba).
• Blueprint, repositório ↗ (abre em outra aba).