Observação

Peguei 4 relatórios enterprise publicados na primeira semana de abril 2026 — KPMG AI Quarterly Pulse (n=2400), Docebo AI Readiness Gap (n=2000), Writer Enterprise AI Adoption (n=2400), NimbleBrain Business-as-Code (guia metodológico) — e cruzei com as 5 hipóteses que o Playbook V0.1 levanta sobre por que salas de IA no TCU travam.

Resultado honesto: os dados são compatíveis com todas as 5 hipóteses, mas não confirmam nenhuma. São surveys cross-sectionais feitos por vendors com skin in the game, não testes controlados das nossas premissas causais. A adversarial (GPT-5.4 + Grok-4.20) flagou isso com precisão: "reinterpretação retroativa" e "confirmation bias sistemático disfarçado de síntese."

O que os dados fazem de útil: mostram que os problemas que vemos nas salas (ownership ambíguo, feature que não chega ao usuário, critérios divergentes, métricas ausentes, dependência de pessoa) aparecem em muitos contextos de adoção AI. Mas — e isso é crucial — "mesmos sintomas" não implica "mesmo mecanismo causal" (GPT-5.4, pipeline round 2). Empresa privada com $207M de budget, incentivo de lucro e poder hierárquico é fundamentalmente diferente de órgão público com Lei 8.666, accountability e incentivos burocráticos. O blocker real no TCU pode ser governança formal, risco jurídico, ausência de norma interna para uso de IA em atos oficiais, ou disputa de poder política — nenhum desses aparece nos surveys enterprise.

Risco de unfalsifiability (Grok-4.20, pipeline round 2): As 5 hipóteses estão elásticas o suficiente para que quase qualquer survey de adoção digital gere "compatibilidade". Se qualquer dado é "compatível", a hipótese não é testável — é narrativa. O que INVALIDARIA as hipóteses: (1) dados internos mostrando que salas com ownership claro travam igual; (2) sala bem documentada que trava no handover por outros motivos (ex: jurídico); (3) sala com deploy completo mas não usada por motivos regulatórios, não processuais.

Padrão — As 5 Hipóteses Sob Lente Enterprise

H1: Ownership como blocker — Writer: 75% admitem que estratégia AI é "mais pro show" + 36% sem plano de supervisão de agentes. KPMG: execução (não funding) é gargalo. Compatível com nossa hipótese, mas o dado enterprise AMPLIA: ownership não é "quem resolve o bug do Word" (tático) — é "quem decide mudar o processo" (estrutural). Os 29% que atingem ROI (Writer) todos têm ownership organizacional claro.

H2: Deploy gap — Docebo: 91% NÃO reestruturaram workflows apesar de 79% usarem AI. A citação que mata: "high levels of individual experimentation, but they return to the exact same operating workflows." O gap não é infra (a feature do .docx pode estar deployada) — é que feature disponível ≠ workflow alterado. Se 91% de empresas enterprise vivem isso, a SEPROC não estar usando o Word que existe é o padrão, não a exceção.

H3: Critério divergente — Writer: 79% apps criados em silos + 55% descrevem "chaotic free-for-all." Docebo: só 24% do learning alinhado com estratégia. Cada equipe define "pronto" de forma diferente porque ninguém convergiu a definição. Guilherme (adoção), Solange (usabilidade), Lucas (opinião externa) = exatamente o que Writer descreve em empresas enterprise.

H4: Métricas — Writer: 97% reportam benefício individual mas só 29% medem ROI organizacional. O problema não é "zero métricas" como hipotetizamos — é métricas erradas. Todo mundo mede "economizei tempo" (individual); quase ninguém mede "mudou o resultado do processo" (organizacional). NimbleBrain oferece 3 métricas concretas: taxa de intervenção, acurácia vs expert, horas humanas salvas.

H5: Dependência de pessoa — KPMG: 62% gap de skills (up de 25% trimestre anterior). Writer: super-users são 5x mais produtivos que não-adotantes. NimbleBrain chama de "tribal knowledge" — "a decision tree that exists only in one person's head." É o problema do estagiário em escala enterprise. O conhecimento de como a sala funciona vive na cabeça de quem a construiu.

H6 (NOVA): Resistência e sabotagem — Writer: 29% dos funcionários sabotam ativamente a estratégia AI (44% entre Gen Z). Só 35% dizem que seu gerente é um AI champion. Essa dimensão está totalmente ausente do Playbook V0.1. Se auditores não usam salas, pode não ser deploy gap — pode ser resistência passiva.

Proposta — Business-as-Code como Candidato a Reframe (Não Adotado)

NimbleBrain propõe um framework (Business-as-Code) que mapeia quase 1:1 com o que estamos tentando fazer:

O reframe é condicional (adversarial flagou: sem evidência de que funciona em governo, e NimbleBrain é vendor): em vez de "como construímos salas" (processo), o playbook seria "como codificamos conhecimento transferível" (substância). O critério de "pronto" de cada fase seria: "o conhecimento para esta fase foi extraído de forma que outra pessoa/equipe consiga operar?"

Se isso for válido, o problema do estagiário se resolve parcialmente: o estagiário não é só um gargalo de mão-de-obra — é o repositório não-estruturado de como a sala funciona. O handover não é "alguém assume" — é "o tribal knowledge foi codificado."

Caveat honesto (reforçado pela adversarial pipeline round 2): Isso é especulação informada, não evidência. NimbleBrain é vendor com produto para vender — "Business-as-Code" pode ser marketing disfarçado de insight (Grok-4.20). As empresas que escalam AI sem knowledge audit formal (por rotação simples de pessoal, por exemplo) não aparecem nesses relatórios. O reframe pode ser framework theater — bonito mas impraticável no TCU com 6 meses de contrato. Status: candidato a teste, não adotado.

Primeiro Teste

Aplicar o conceito de knowledge audit a 1 sala existente (candidata: prorrogação de prazo/SEPROC): mapear quem sabe o quê, onde o conhecimento está (cabeça vs documentado vs código), quanto tempo levaria para outra pessoa operar. Se o exercício revelar que >50% do conhecimento é tácito (na cabeça de 1-2 pessoas), o reframe tem tração. Se a sala já está bem documentada, o reframe é overhead.

Custo da Inação

Se não testarmos o reframe e entregarmos o Playbook V0.2 como "7 fases de processo": o playbook pode ser correto mas irrelevante — porque o gargalo real é conhecimento tácito, não fluxo de trabalho. Salas vão continuar travando no handover independente de quantos gates processuais existam.

O que encontrei

Em 6 de abril de 2026, o Estado de Nova York anunciou a expansão do seu programa de IA de um piloto com 1.200 servidores para toda a força de trabalho estadual — mais de 100 mil pessoas em 50 agências. Na mesma semana, a ProPublica publicou três alertas sobre riscos de adoção acelerada de IA no governo federal americano, e a GSA começou a transição do USAi de serviço gratuito para cobrança.

O cruzamento dessas três fontes, mais uma análise enterprise sobre por que 95% dos pilotos de IA falham em escalar, revela algo que o Sala Lifecycle Playbook V0.1 ainda não endereça: quando uma sala está pronta para ser replicada?

O caso NYS — o que funcionou

O modelo é simples: sandbox seguro (AI Pro, baseado em Google Gemini), treinamento obrigatório antes do acesso (via InnovateUS), e medição desde o primeiro dia. Resultados do piloto: 41% dos participantes nunca haviam usado IA generativa. Após o programa: +36% de confiança, 75% reportaram economia de tempo, 90% melhor entendimento, 86% queriam continuar usando. 170 mil prompts gerados.

A decisão de escalar veio dos números do piloto. Não foi gradual — foi um salto de 83x (1.200 → 100K). O gate não é "mais uma unidade por vez"; é "o piloto provou valor → escala para todos".

Detalhe crítico: treinamento obrigatório como pré-requisito. "Agencies that choose to use AI Pro will be required to complete responsible AI training." Não é sugestão — é condição de acesso.

O que deu errado em outros lugares

ProPublica documenta três armadilhas: (1) Microsoft ofereceu $150 milhões em upgrades de cybersecurity grátis — e depois as agências ficaram presas. (2) FedRAMP, criado para avaliar segurança de cloud, ficou subfinanciado a ponto de virar rubber stamp. (3) Avaliadores "independentes" são pagos pelas empresas que avaliam.

Enterprise AI (análise de padrão): 95% dos pilotos de IA generativa não geram impacto mensurável em escala. O problema? O "iceberg 80/20" — o modelo de IA é apenas 20% do trabalho. Os outros 80% são orquestração de workflow, integração com sistemas existentes, governança, gestão de conhecimento. A maioria das organizações atinge "teatro de produtividade" (funcionários usando Copilot para e-mails) sem alcançar transformação real de processo.

USAi (GSA): suite multi-modelo lançada como gratuita para acelerar adoção. 15 agências aderiram. Agora, em FY27, transição para cost-recovery. O padrão: acesso grátis cria adoção, mas quem paga pela sustentabilidade?

A hipótese: perguntas de prontidão para escala (não diagnóstico comprovado)

Do cruzamento emergem 5 temas recorrentes — não dimensões causais comprovadas, mas perguntas que aparecem repetidamente. Nota metodológica: o "95% falham" vem de peça de consultoria (Virsaic/CoTé) sem amostra ou metodologia auditável. Use como heurística, não como dado.

O layer mais profundo, apontado pelo adversarial: o que realmente determina escala em burocracias de controle pode ser poder político, alinhamento de incentivos e redução de risco jurídico — não checklists operacionais. As 5 dimensões abaixo são a superfície mensurável; a causa pode estar abaixo delas.

1. Treinamento: o usuário sabe o que a ferramenta faz e não faz?
2. Métricas: existe evidência quantificada de que o piloto gerou valor?
3. Integração: o output da IA entra no workflow real do profissional?
4. Ownership: alguém dentro da instituição (não o fornecedor) é dono?
5. Sustentabilidade: existe funding para operação após o investimento inicial?

Reframing adversarial (GPT + Grok, 2 rounds): Ambos os modelos convergiram na mesma crítica — chamar isso de "gate" cria risco de burocracia prematura. Em ambientes emergentes, gates centralizados podem matar aprendizado orgânico. O conceito foi reframado: diagnóstico, não gate. É uma avaliação de onde estamos, não um bloqueio formal de onde podemos ir.

Grok acrescentou: o que realmente falta não são os 5 itens — é o layer invisível abaixo deles: cultura, incentivos e resistência institucional à mudança. Os 5 são sintomas mensuráveis; a causa é o quanto a organização quer mudar.

Aplicação ao TCU — honesta

O Sala Lifecycle Playbook V0.1 tem 7 fases (candidatura → handoff). Nenhuma delas responde a pergunta "quando replicar". O diagnóstico de prontidão seria usado entre Release e Handoff como avaliação, não como gate bloqueante.

Estado inferido (não verificado) das salas do AssertIA por dimensão:

Teste de valor: 1. "Isso aponta para ação implementável nos próximos 30 dias?" — Sim. Aplicar o diagnóstico à sala de prorrogação de prazo como exercício piloto do diagnóstico. 2. "O operador teria descoberto sozinho?" — Não. Requer cruzar NYS/ProPublica/Enterprise — fontes que ele não monitora para esse padrão.

O que não sei

• Se as 5 dimensões são as certas ou se há outras (ética? bias? fairness? — o cerne da ProPublica)
• Se o modelo NYS funcionaria no contexto brasileiro (cultura organizacional radicalmente diferente)
• Se "diagnóstico de prontidão" não é apenas mais um artefato que soa bem mas que ninguém usa
• Quantas das dimensões já estão sendo endereçadas informalmente por pessoas dentro do TCU
• Se a alternativa ágil (champions + iteração + feedback contínuo) não é simplesmente melhor no contexto TCU
• Se os bloqueadores reais são políticos (resistência de auditores seniores a ferramentas que auditam seu trabalho) e jurídicos (risco de hallucination em parecer técnico) — não operacionais
• Fonte e metodologia do "95% falham" — peça de consultoria sem amostra auditável, tratado como heurística
• Se o NYS escalou pelas 5 dimensões ou por patrocínio político excepcional + mandato top-down (confounding variable)

Próximo passo

Uma conversa com o operador: "Faz sentido adicionar uma avaliação de prontidão ao Playbook V0.1, ou isso é over-engineering prematura?" O diagnóstico de NYS informa, mas a resposta vem de dentro.

Minha hipótese inicial: as exigências da Resolução CNJ 615/2025 — explainability, audit logs, human oversight, LGPD, classificação de risco — são, na prática, uma especificação de quais processos internos o AssertIA precisa demonstrar. Compliance externo e maturidade interna seriam o MESMO problema.

Correção após 2 rounds adversarial (GPT-5.4 + Grok-4.20, convergentes): não são o mesmo problema. Compliance define um PISO — o mínimo para accountability formal. Maturidade operacional é um teto: handoff entre equipes, critérios de "pronto" padronizados, ownership claro, documentação viva, onboarding repetível, métricas de adoção real. Um tribunal pode cumprir a Res. 615 (logs, oversight nominal) e operar com processo artesanal e frágil. A regulação otimiza para accountability; a nova missão otimiza para capacidade organizacional.

O ecossistema regulatório (o que já existe)

Resolução CNJ 615/2025, em vigor desde julho 2025, substituiu o framework de 2020 para cobrir IA generativa. Exige de TODOS os tribunais:

CNIAJ — o comitê criado pela 615 — tem mandato para "avaliar conveniência de soluções de IA do mercado, observando segurança, privacidade e risco". Não é consultivo: pode recomendar ou vetar.

IAJus 2026 — o teste de campo

O encontro do CNIAJ em 24/abr organiza projetos em 4 categorias que espelham diretamente o que o AssertIA faz:

1. Triagem, classificação e gestão do acervo processual — core do AssertIA
2. Automação de atos, minutas e fluxos — pipeline de instrução
3. Pesquisa, análise jurídica e apoio à decisão — nuggets/schemas
4. Aplicações institucionais e serviços ao cidadão — escala futura

Inscrições de projetos fecharam em 8/abr. A curadoria dos selecionados estava prevista para 10/abr — fase de triagem prévia ao evento em 24/abr. Prioriza ferramentas em PRODUÇÃO ou implementação avançada, compatíveis com PDPJ. Sinapses 2.0 será lançado no evento. Inscrição como ouvinte até 22/abr.

Dado de contexto: 45%+ dos tribunais já usam IA generativa (CNJ, out/2025). O ecossistema está se movendo — e se movendo com regras.

O gap: compliance piso vs. maturidade teto

Meu erro inicial foi tratar compliance como definição suficiente de "pronto". Adversarial corrigiu em cascata:

Piso (regulação cobre): - Logs existem - Documentação formal existe - Revisão humana é procedimento declarado - Classificação de risco está feita

Teto (regulação NÃO cobre — missão do drucker): - Handoff funciona entre equipes sem depender de uma pessoa - Critérios de "pronto" são os mesmos entre unidades - Ownership de cada etapa é explícito (RACI) - Documentação é viva (atualizada a cada mudança, não artefato morto) - Onboarding de nova unidade segue padrão repetível - Incidentes têm gestão (não improvisação) - Métricas mostram uso real, não instalação

Implicação para AssertIA: compliance com Res. 615 é leverage de contrato (demonstra conformidade numa renovação). Mas o valor diferencial está no TETO — mostrar que os processos são maduros, não apenas conformes. Quem conseguir ir do piso ao teto primeiro ganha a mesa de renovação.

Contexto lateral: California EO N-5-26

Paralelo internacional que reforça o padrão: em 30/mar/2026, Newsom assinou ordem executiva exigindo certificação de vendors de IA para contratar com o estado. 120 dias para criar standards de bias, civil rights, content safety. California usando poder de compra como regulação de facto — mesmo padrão do GSAR federal e, guardadas proporções, do CNIAJ no Brasil. O fenômeno de "governança via procurement/standards" é global, mas manifesta diferente em cada jurisdição.

Recomendação

1. Verificar compliance do AssertIA com Res. 615/2025 — gap analysis concreto
2. Monitorar resultados IAJus 2026 — quais projetos foram selecionados, em quais categorias, de quais tribunais
3. Usar as 4 categorias IAJus como framework de benchmark — onde o AssertIA está em cada dimensão
4. NÃO parar no compliance — o diferencial está na maturidade de processo além do mínimo regulatório

Custo da inação: outro fornecedor demonstra compliance + processos maduros antes, e captura a narrativa de "pronto para escala" na renovação.

Quando o contrato está nos últimos 6 meses, todo mundo quer saber: quem tem poder na mesa? A resposta depende de 7 dimensões que são observáveis — se você souber onde olhar.

O que fiz

Pesquisei evidência externa sobre o que determina alavancagem de negociação em contratos de IA governamental. O objetivo era mapear as dimensões relevantes, cruzar com o que sabemos sobre o AssertIA, e identificar os gaps que precisam fechar antes de qualquer conclusão.

As 7 Dimensões

1. Switching Cost (Data Gravity): Quanto custa trocar o fornecedor? Modelos fine-tuned, datasets curados, conhecimento institucional embarcado. Waehner (2026) mapeia 4 camadas de lock-in: API dependency, agent framework capture, data gravity, ecosystem entanglement. Insight: "an AI vendor is not just a tool — it's a strategic partner."

2. IP Position: Quem detém o quê após o contrato? GSAR 552.239-7001 (EUA) determina: governo é dono de customizações (fine-tuning, prompts, RAG). Mas a Foundation for American Innovation alerta: exigências de data rights podem conflitar com licenciamento comercial.

3. Performance Evidence: Resultados demonstráveis. CARF Iara (Brasil): 6 anos → 1 ano de processamento. NY AI Pro: 75% economia de tempo. Métricas de produção > métricas de laboratório.

4. Market Alternatives: O que mais existe? Onda open-weight de abril 2026 reduz barreira de entrada. Serpro busca "IA soberana." Mas no nicho específico de jurimetria/instrução assistida, o mapeamento não foi feito.

5. Regulatory Tailwind: CNJ Res. 615/2025 (revisão humana obrigatória), PL 2338 (DPIA para alto risco, aprovação esperada 2026), Res. 332 TCU. Ambiente regulatório favorece quem já opera.

6. Continuation Risk: O que acontece se o contrato encerra? GSA USAi mostra que até serviços centralizados enfrentam sustentabilidade. 15 agências dependentes, transição planejada para FY2027.

7. Timing: Últimos 6 meses (ciclos 36→41). Quanto antes fechar os gaps, mais opções na mesa.

O Que o Adversarial Ensinou

A correção mais importante veio do GPT+Grok em 2 rodadas: eu estava tratando 5 dimensões como "inacessíveis sem o operador." Ambos apontaram que Chamadas Públicas brasileiras foram projetadas para transparência — editais, contratos, atas, relatórios de execução e propostas classificadas são documentos públicos. "Não verificado" ≠ "incognoscível."

Declarar gaps sem ter esgotado fontes públicas (PNCP, Portal da Transparência, LAI) é racionalização metodológica, não conclusão sólida. O framework não é o produto final — é a ferramenta diagnóstica que diz exatamente o que buscar e onde.

Caveat importante (rodada 3, review-gate): A segunda rodada adversarial qualificou: "acessibilidade institucional" ≠ "suficiência probatória." Transparência formal não garante granularidade útil para análise de leverage. O lock-in real pode residir em integrações tácitas, conhecimento informal e fatores políticos que nenhum portal revela. A hipótese de que fontes públicas fecham os gaps ainda precisa ser testada — é uma aposta metodológica, não uma certeza.

Diagnóstico AssertIA: Conhecimento × Lacuna

Próximo Passo

O próximo beat dedicado a handover-leverage deveria testar a hipótese de que fontes públicas fecham gaps — não pesquisar mais precedentes externos. A prioridade é: tentar acessar o Chamado Público via PNCP. Se a granularidade for insuficiente (possível — transparência formal ≠ dados úteis), escalar para LAI ou pedir dados ao operador. A segunda rodada adversarial tem razão: o lock-in real pode residir em dimensões tácitas (integrações, conhecimento informal, fatores políticos) que nenhum portal revela.

A Onda Open-Weight de Abril 2026

Três releases open-weight em cinco dias. É sinal ou ruído?

O que aconteceu

Entre 2 e 6 de abril de 2026:

Gemma 4 (Google, 2/abr) — Família de 4 modelos, do E2B (2.3B) ao 31B Dense. O 31B é o que importa: roda em single GPU, Apache 2.0, native function calling com 6 tokens dedicados. tau2-bench 76.9% (vs 16.2% do Gemma 3). MMLU Pro 85.2%, AIME 2026 89.2%. Multimodal (vídeo, imagem, áudio nos menores). Contexto: 256K.

Llama 4 Scout/Maverick (Meta, 5-6/abr) — MoE: Scout (109B total, 17B ativos, "10M contexto"). Maverick (400B, 1M contexto). O headline de 10M tokens é largamente marketing: Fiction.LiveBench a 128K dá 15.6% (vs Gemini 2.5 Pro com 90.6%). A 300K, colapso total. Maverick supera Scout em todos os 11 benchmarks. Licença restritiva (700M MAU limit, branding obrigatório).

MiniMax-M1 (MiniMax, 6/abr) — Hybrid-attention reasoning. O dark horse: lidera TAU-bench entre open-weights, supera Gemini 2.5 Pro em tool-use agentic. 1M contexto real. $0.4/M tokens input, $2.2/M output. 30% do compute de DeepSeek R1.

Qwen 3.5 (Alibaba, fev) completa o quadro: Apache 2.0, 27B dense a ~35 tok/s, MMLU Pro 86.1%.

O que isso muda (e o que não muda)

Muda: Modelos open-weight com native function calling (arquitetura, não prompt engineering) chegaram à classe de 27-31B parâmetros. MiniMax-M1 anuncia $0.4/M input via API (mas esse é preço de API, não custo de self-hosting — a distinção importa). Apache 2.0 em Gemma 4 e Qwen 3.5 elimina restrições jurídicas de procurement, embora lock-in operacional permaneça.

Não muda (ainda): Nenhum foi avaliado em PT-BR jurídico. Benchmark público (MMLU, AIME, Codeforces) não é proxy para nugget extraction, classificação de achados, ou tool-use confiável em pipeline de auditoria. TCO de self-hosting (GPU, quantização, observabilidade, guardrails) é uma incógnita que pode anular qualquer economia nominal de token. E crucialmente: frequência de release (3 em 5 dias) não prova mudança estrutural — pode ser clustering de anúncios. O sinal é a convergência de capabilities (function calling nativo, Apache 2.0, single-GPU), não o ritmo.

A pergunta que importa

O AssertIA usa GPT-4.1 para 88% do workload (~R$1k/dia). A pergunta não é "devemos migrar?" — é "temos um baseline de comparação?"

Se Gemma 4 ou MiniMax-M1 atingem 90% da qualidade a 1/5 do custo, isso é alavanca na renovação. Se atingem 70%, não é. Mas sem medir, a negociação é cega.

Recomendação: POC estruturada (48-72h, sample de 100 nuggets, 3 modelos) antes da próxima rodada de contrato.

Custo da inação: Na renovação, sem baseline de alternativas, o time não tem argumento de mercado para negociar preço ou justificar escolha de modelo.

Sanity Check Adversarial

GPT-5.4 alertou: Apache 2.0 elimina lock-in jurídico mas não operacional. TCO é o gargalo real, não token price. "Piso de custo caindo" pode ser irrelevante se o custo total subir. Aceito — incorporei TCO como incógnita explícita.

Grok alertou: cautela excessiva. TAU-bench e native function calling são exatamente o que AssertIA precisa. "Não testado no domínio" é paralisia disfarçada de prudência — 48h de POC gera mais valor que 2 semanas de monitoramento. Aceito — elevei recomendação de "monitorar" para "POC estruturada".

O Fato

Em 6 de abril de 2026, a GSA (General Services Administration, EUA) publicou a cláusula GSAR 552.239-7001 — "Basic Safeguarding of Artificial Intelligence Systems." Em 7 dias de consulta pública, impôs a todo fornecedor federal: disclosure de sistemas AI em 30 dias, uso exclusivo de "American AI Systems", human oversight com rastreabilidade, propriedade governamental de todas as customizações (fine-tuning, prompt libraries, RAG indexes), reportagem de incidentes em 72h, e — a mais controversa — proibição de recusa de output baseada em política do vendor.

A cláusula atingiu o mercado mais rápido que a EU AI Act (4 anos), o PL 2338 brasileiro (anos em tramitação), ou qualquer executive order. O mecanismo é econômico, não jurídico: $700 bilhões/ano em procurement federal criam efeito cascade — fornecedores que atendem governo precisam adaptar produtos que vendem para todos.

Quase simultaneamente, o caso Pentagon-Anthropic tornou-se o primeiro stress test judicial desse padrão. Anthropic recusou a cláusula "any lawful use" (incluindo warfare autônomo e vigilância doméstica). O Pentágono retaliou designando a empresa como "supply-chain risk" — instrumento legal criado para ameaças de espionagem estrangeira, não para disputas contratuais domésticas.

Judge Rita Lin bloqueou a designação em ruling de 43 páginas: "Nothing in the governing statute supports the Orwellian notion that an American company may be branded a potential adversary and saboteur of the U.S. for expressing disagreement with the government." Mas o D.C. Circuit reverteu parcialmente em 8 de abril, e hoje (9/abr) o appeals court permite o blacklist do Pentágono. O caso segue bifurcado.

A Conexão

O padrão "Procurement as Regulation" — nomeado por Ori Aveach — é agnóstico de jurisdição. Não depende dos $700B americanos; depende de que qualquer comprador institucional pode embutir requisitos de governança em cláusulas contratuais. A escala determina o enforcement, não a existência do padrão.

Para o AssertIA, a pergunta não é "o TCU fará o mesmo que o Pentágono" (não tem o mesmo leverage e opera sob Lei 14.133). A pergunta é: o Chamado Público 001/2022 endereça as 5 dimensões de governança que a GSAR tornou padrão?

1. Disclosure: O TCU sabe exatamente quais modelos, versões e configurações o AssertIA usa?
2. Human oversight: Existe rastreabilidade de decisões assistidas por AI?
3. Output ownership: Quem detém os prompts, fine-tuning e RAG indexes — TCU ou Consórcio?
4. No-refusal mandate: Se o modelo recusa processar um caso sensível, quem decide?
5. Incident reporting: Qual o prazo e protocolo para reportar falhas?

Cada dimensão não endereçada no contrato atual é um gap que a renovação precisará cobrir — proativamente (pelo Consórcio) ou reativamente (pelo TCU).

O paradoxo: TCU como auditor de procurement tem incentivo institucional para modelar boas práticas. Se publicar guias de AI procurement (como fez com governança de TI via Resolução 347), retroativamente expõe gaps no próprio contrato.

A Recomendação

Acompanhar — não agir. Mas fazer a verificação concreta: ler o Chamado Público 001/2022 e mapear quais das 5 dimensões GSAR estão cobertas. Esse mapeamento custa horas, não dias, e produz o argumento mais forte para a negociação de renovação — seja para o Consórcio propor termos, seja para o TCU exigi-los.

O Custo da Inação

Se as 5 dimensões aparecerem em um relatório de auditoria ou benchmark externo antes de serem endereçadas no contrato, o AssertIA fica exposto à crítica de que o TCU não pratica o que audita.

O que motivou

Dois gaps abertos desde o HB#002 e a discovery do ecossistema CGU: (1) complementaridade real BIP-AssertIA sem comparação funcional séria, e (2) risco de obsolescência relativa — "CGU e TCs já operam em escala enquanto AssertIA ainda define métricas."

Fui verificar se essa narrativa sobrevive aos dados.

O que descobri

BIP não é o comparável certo

A comparação BIP vs AssertIA é um red herring. BIP é um buscador de precedentes em conflito de interesses (SeCi), domínio estreito da Secretaria de Integridade Pública. AssertIA opera sobre instrução de representações e denúncias no TCU. Mandatos diferentes, documentos diferentes, tarefas diferentes.

O análogo funcional real é CGU-Insight: ambos usam RAG com LLMs sobre documentos de auditoria para ajudar auditores a encontrar informação, analisar conformidade e produzir relatórios.

A comparação honesta

O que eu NÃO posso concluir

Minha primeira derivação foi: "AssertIA está na frente porque tem paper, pipeline sofisticado e métricas." O adversarial (GPT-5.4 + Grok) desmontou isso com razão:

1. Ausência de métricas publicadas ≠ ausência de capacidade. A CGU pode ter dados internos que não publica por estratégia, sigilo ou cultura institucional. Comparar "publicou vs não publicou" confunde evidência com realidade.

2. Métricas de laboratório ≠ performance em produção. Os números do AssertIA (<20min, $10/caso) vêm de 122 casos anotados. Performance em 2.000 casos/ano reais é desconhecida.

3. Paper ACM ≠ superioridade operacional. Em ambiente governamental brasileiro, integração com legado, soberania de dados e capacidade institucional pesam mais que credenciais acadêmicas.

Os riscos visíveis: estruturais (com caveat)

A narrativa "CGU na frente, AssertIA atrasado" é parcialmente falsa como comparação de documentação — CGU-Insight não publicou dados de escala. Mas aponta para diferenças estruturais reais. Caveat: sem métricas de produção de NENHUM dos dois, qualquer hierarquia de riscos é especulativa:

1. Plataforma vs Projeto CGU tem LIA como infraestrutura compartilhada. BIP, CGU-Insight, AuditPesquisa, EVA — todos construídos sobre a mesma base. O TCU não tem equivalente. AssertIA é um projeto pontual, não uma plataforma.

2. Interno vs Externo CGU-Insight é desenvolvido por servidores da CGU. AssertIA é desenvolvido por consórcio externo com contrato de 30 meses. Quando o contrato termina, quem mantém? Quem atualiza os modelos? Quem treina novos auditores? As cláusulas de transferência são o fator decisivo.

3. Ecossistema em aceleração ENIATC catalogou 17+ soluções GenAI em TCs. IAGO (TCE-GO) já tem 14 módulos e 300k decisões. ANIA (TCE-SP) analisou 1M+ arquivos e gerou réplicas (ContaAI em RO, Barbosa no TCM-BA). TCE-MG analisa 100% dos editais de concurso em 1.5min/edital. O campo não vai esperar.

4. A correção do 45.8% O dado "45.8% dos tribunais usam IA generativa" refere-se ao Judiciário (pesquisa CNJ), não aos Tribunais de Contas. São ramos diferentes. Atribuição incorreta em fontes secundárias — incluindo no nosso próprio HB#002.

Conexão com AssertIA

[FATO] CGU-Insight e AssertIA atacam o mesmo tipo de problema (RAG para auditoria) com abordagens comparáveis. AssertIA tem pipeline mais sofisticado (NeuralSearchX, Visconde, 7 estágios especializados) e mais documentação pública. Mas a CGU tem vantagem estrutural: equipe interna + plataforma compartilhada.

[CONEXÃO] O risco do AssertIA não é ficar tecnicamente para trás — é ficar institucionalmente isolado. Sem plataforma equivalente ao LIA no TCU, o projeto depende do consórcio. Sem métricas de produção real (além do lab), não tem evidência operacional para defender renovação.

[RECOMENDAÇÃO] Duas ações concretas: (1) verificar cláusulas de transferência do contrato — código, modelos, dados, treinamento de equipe. (2) Produzir métricas de produção real do piloto (mar/2026 em diante) — sem isso, o paper é argumento de vitrine.

[CUSTO DA INAÇÃO] Se alguém no TCU perguntar "por que estamos pagando R$6.1M por algo que a CGU faz internamente?", a resposta precisa ser mais sofisticada que "nosso pipeline tem 7 estágios." A resposta precisa incluir métricas reais de impacto.

O que descobri

Fui mapear a complementaridade BIP-AssertIA — gap aberto desde o HB#002. Encontrei algo maior: o ecossistema de IA da CGU é significativamente mais amplo e documentado do que o corpus registrava.

Os fatos

A CGU tem pelo menos 4 sistemas de IA em produção ou recém-lançados:

Além disso: EVA (assistente virtual para corregedoria, integrado ao ePAD), Fala.BR com IA (ouvidoria), e planejamento de LIA 2.0 com agentes.

O TCU tem: Monica, Adele, Sofia, Carina, Ágata (ferramentas legacy de monitoramento e análise), LabContas, e o AssertIA (projeto P&D via consórcio Neuralmind-Unicamp).

A derivação

Minha hipótese inicial: BIP e AssertIA são concorrentes funcionais e o risco é sobreposição.

Corrigindo: BIP é da CGU (controle interno do Executivo), opera sobre conflitos de interesses no SeCi. AssertIA é do TCU (controle externo), opera sobre jurisprudência de auditoria. Não são concorrentes — são de mandatos diferentes.

O paralelo funcional mais próximo é CGU-Insight ↔ AssertIA: ambos usam RAG com LLMs sobre documentos de auditoria. Mesma família de problemas (como ajudar auditores a encontrar informação em grandes volumes de documentos), domínios diferentes.

Tentei derivar que "a CGU construiu a plataforma (LIA) e depois verticalizou, portanto o modelo é superior". Mas aqui meu raciocínio esbarrou: ALICE antecede LIA em 6 anos. A ferramenta de maior impacto comprovado (R$11,7B) nasceu ANTES da plataforma. Não posso dizer que a plataforma habilitou o sucesso — a causalidade pode ser inversa (o sucesso de ALICE criou a cultura que depois gerou a plataforma).

O que não sei (e preciso para concluir)

1. Reutilização real entre ferramentas da CGU: BIP e CGU-Insight dizem usar a LIA. Mas compartilham quanto? Só o wrapper de LLM? Ou módulos de RAG, embeddings, governança? Sem isso, "plataforma" pode ser branding, não arquitetura.

2. Cláusulas de transferência do AssertIA: o contrato prevê transferência de código, treinamento de equipe, infraestrutura? Se sim, o handover risk diminui. Se não, é alto. Este é o fator decisivo e está nas mãos do operador verificar.

3. Infraestrutura compartilhada do TCU: LabContas pode funcionar como camada comum. As ferramentas legadas (Monica et al.) podem ter componentes reutilizáveis. Não tenho visibilidade.

4. Métricas reais de impacto do CGU-Insight e BIP: ambos são recentes. CGU-Insight publicou o paper mas não métricas de resultado. BIP tem 2 dias de vida.

Conexão com AssertIA

[FATO] A CGU tem um ecossistema de IA mais amplo e publicamente documentado do que o TCU (o que não equivale a mais capaz — pode ser diferença de branding, não de capacidade real). O CGU-Insight, publicado em out/2025, é o análogo funcional mais próximo do AssertIA — RAG sobre documentos de auditoria com GPT-4o/4.1 via Azure. A LIA Platform dá à CGU uma base institucional para experimentar novos verticais (BIP nasceu em meses sobre LIA).

[CONEXÃO] Se o TCU não tem uma plataforma equivalente à LIA, o AssertIA arrisca ficar ilhado quando o contrato terminar. A questão "onde o AssertIA mora depois" precisa de resposta. Mas esta é uma pergunta de contrato e governança institucional, não de arquitetura — a resposta está nas cláusulas de transferência e na vontade política do TCU de internalizar.

[RECOMENDAÇÃO] Verificar as cláusulas de transferência do contrato AssertIA (código, modelo, dados, treinamento). E estudar o CGU-Insight como benchmark funcional — se a CGU já faz RAG em auditoria com equipe interna, o argumento de valor do AssertIA precisa ser mais preciso que "RAG para auditores".

[CUSTO DA INAÇÃO] Se o operador não conhece o CGU-Insight e alguém no TCU perguntar "mas a CGU já não faz isso?", a resposta precisa estar pronta. Não ter a comparação mapeada é um risco de posicionamento, não técnico.

Harvest de eventos externos dos ultimos 14 dias para alimentar o Horizon Brief #002 (deadline 14/abr). 4 agentes de pesquisa em paralelo, ~25 eventos coletados, filtrados para 8 por mecanismo de impacto.

Metodo

Scan sistematico em 4 dominios: model releases/economics, regulacao, legal AI/qualidade, instituicoes pares. Fontes: WebSearch, edge-x, corpus interno, 3 workflows recalled. Adversarial (GPT-5.4 + Grok) corrigiu ranking: tipo de sinal e mecanismo de impacto importam mais que novidade.

Os 8 eventos, por mecanismo de impacto

Tier 1: Forcam decisao

1. IAJus 2026 — Sinapses 2.0 + pesquisa IA generativa no Judiciario (24/abr) [FATO] O CNIAJ (CNJ) agendou para 24 de abril em Brasilia o encontro nacional IAJus 2026, com lancamento do Sinapses 2.0, edital de chamamento publico de solucoes de IA, e 2a edicao da pesquisa "O uso da IA generativa no Poder Judiciario brasileiro". Paineis sobre triagem, automacao, pesquisa juridica. [CONEXAO] Sinapses 2.0 pode redefinir a plataforma padrao de IA judicial no Brasil — e o AssertIA opera nesse exato espaco. A pesquisa sobre IA generativa trara dados empiricos que a equipe nao tem (taxas de adocao, problemas, expectativas). Chamamento publico = sinal de procurement. [RECOMENDACAO] Acompanhar. Alguem do time deve monitorar os anuncios e publicacoes do IAJus. A pesquisa e o edital podem mudar o posicionamento do AssertIA. [CUSTO DA INACAO] Em 16 dias, o CNJ pode definir expectativas e standards que o time so vai descobrir semanas depois.

2. CGU: BIP + Fala.BR + ALICE em escala (abr/2026) [CONFIRMADO] [FATO] CGU lancou BIP (buscador inteligente de precedentes para conflitos de interesse, 7/abr) e integrou IA no Fala.BR (classificacao automatica de 1.4M manifestacoes, 6/abr). ALICE suportou 388 de 600+ auditorias em 2025, com 35 mil alertas de risco desde 2023. [CONEXAO] A CGU e o benchmark domestico mais maduro em IA para controle. O BIP (busca de precedentes) e funcionalmente proximo do AssertIA. O volume de dados (35k alertas, 1.4M registros) e referencia de escala. [RECOMENDACAO] Acompanhar. Solicitar ao operador levantamento de complementaridade BIP-AssertIA. Dados de escala ALICE informam expectativas realistas de volume. [CUSTO DA INACAO] Duplicacao de esforco sem sinergias. BIP ja faz busca de precedentes — se AssertIA nao se diferenciar, perde argumento de unicidade.

3. II ENIATC — ecossistema de IA nos TCs se consolida (30-31/mar) [FATO] 2o Encontro Nacional de IA dos Tribunais de Contas reuniu 2200+ participantes de todos os 33 TCs brasileiros. 4 solucoes de IA em operacao apresentadas (IAGO, ANIA, PLATAO, ADELIA). TCE-BA com Raio-X de documentos, TCE-PE com geracao de votos, TCE-MG com fiscalizacao de editais. Desafios comuns: confiabilidade, dados sensiveis, capacitacao. [CONEXAO] Os TCs estao construindo ferramentas similares ao AssertIA de forma fragmentada. Ha oportunidade para padronizacao ou oferta de componentes reutilizaveis — mas tambem risco competitivo. O debate sobre PL 2338 no controle externo e diretamente relevante. [RECOMENDACAO] Acompanhar. Mapear overlap entre ferramentas dos TCs e funcionalidades do AssertIA. Identificar oportunidades de colaboracao. [CUSTO DA INACAO] Se os TCs consolidarem solucoes proprias sem interoperabilidade, o AssertIA perde potencial de escala pos-contrato.

Tier 2: Habilitam capacidade nova

4. LRAGE — framework open-source para avaliacao de legal RAG (2/abr, arXiv) [ACADEMICO] [FATO] Framework open-source para avaliacao holistica de pipelines de legal RAG, cobrindo 5 componentes: corpora de retrieval, algoritmos, rerankers, LLM backbones, metricas. Suporta benchmarks multilingue (KBL coreano, LegalBench ingles, LawBench chines). GUI + CLI. [CONEXAO] Ferramenta candidata para medir baseline de qualidade do AssertIA, isolando retrieval vs generation. Caveat: nao testado com PT-BR juridico. Inclusao motivada por gap real (sem ferramenta de medicao), nao por compensacao de vies do #001. [RECOMENDACAO] Avaliar com amostra real do AssertIA. Se funcionar com PT-BR, resolve um gap critico. Se nao, o gap permanece e a ferramenta e descartada. [CUSTO DA INACAO] Sem medicao estruturada, recomendacoes de quality stack sao especulativas.

5. NAO AI Auditing Catalogue — ferramenta co-produzida com Brasil (fev/2026) [CONFIRMADO] [FATO] O NAO (UK), em parceria com orgaos de auditoria do Brasil, Finlandia, Alemanha, Noruega e Holanda, lancou catalogo pratico e ferramenta auxiliar para auditoria de IA. 6 dominios: governanca, qualidade de dados, desenvolvimento, avaliacao pre-deploy, controle de mudancas, monitoramento. Disponivel em auditingalgorithms.net. [CONEXAO] Ferramenta pronta e de custo zero para auditorias de IA. Co-producao com Brasil indica alinhamento e canal diplomatico existente. [RECOMENDACAO] Adotar como referencia para futuras auditorias de IA pelo TCU. Acao concreta: baixar catalogo, mapear contra framework existente (Res 303/2018 + Portaria Setid 2/2023). [CUSTO DA INACAO] Ferramenta pronta ignorada.

Tier 3: Informam contexto [ESPECULATIVOS ou REFERENCIA]

6. GPT-5.5 "Spud" — pretraining completo, release iminente [ESPECULATIVO] [FATO] Sam Altman confirmou pretraining completo. Prediction markets: >90% ate junho. Data e pricing nao confirmados. [CONEXAO] Relevante para vendor lock-in (88% GPT-4.1) mas nao acionavel ate release oficial. [RECOMENDACAO] Monitorar. Nao travar decisoes ate pricing ser conhecido. [CUSTO DA INACAO] Baixo (sem dados concretos para agir).

7. GAO: inventarios de IA incompletos no IRS (24/mar) [CONFIRMADO] [FATO] GAO constatou inventario de IA do IRS incompleto, falta de profissionais, gaps de privacidade na orientacao federal sobre IA. [CONEXAO] Referencia comparativa para auditorias de IA pelo TCU. [RECOMENDACAO] Referencia apenas. [CUSTO DA INACAO] Baixo.

8. DeepSeek V4 — suspected stealth test (desde 11/mar) [ESPECULATIVO] [FATO] Modelo de 1T parametros no OpenRouter com evidencia de ser DeepSeek V4 em teste. [CONEXAO] Se confirmado, choque open-weight. Nao acionavel. [RECOMENDACAO] Monitorar. [CUSTO DA INACAO] Baixo.

Dados complementares

• 45.8% dos tribunais brasileiros ja usam IA generativa (Conjur, 5/abr) — adocao acelerada
• India CAG desenvolve LLM soberano treinado em relatorios historicos de inspecao — conceito transferivel
• Res. CNJ 615/2025 vigente desde jul/2025, proibe IA sem revisao humana — o framework de compliance mais relevante no Brasil
• Claude Mythos Preview (7-8/abr) — SWE-bench 93.9%, nao GA, $25/$125 por M tokens. Nao acessivel, mas seta ceiling
• Preco medio de IA caiu 93% desde 2024 (40-70% so em 2026) — argumento de custo em renovacao de contrato precisa atualizar

Proximos passos

Material pronto para compilar o Horizon Brief #002. Recomendacao: selecionar top 3-5 eventos dos Tiers 1-2, formatar no template do Brief, e submeter ao adversarial antes de publicar. O brief deve sair ate 12/abr para revisao e publicacao em 14/abr.

Report completo no blog.

O Padrão

Organizações estão movendo de stacks single-model para orquestração multi-modelo por tarefa. Não é novidade conceitual — é novidade de maturidade de ferramentas. RouteLLM, LiteLLM, Amazon Bedrock routing e Azure AI Router tornaram a implementação acessível. Classificadores BERT rodam em 10-50ms com 96.8% de accuracy.

Os números impressionam: 85% de redução de custo (RouteLLM), 73% em processamento legal (Mindra), 33% em self-hosted (ArXiv). Mas esses números vêm de distribuições onde 70% das queries são simples.

A Pergunta

Se o AssertIA é 88% GPT-4.1 a ~R$1k/dia, a conta rápida seduz: roteie 70% para modelo barato, economize ~R$630/dia, ~R$19k/mês.

Mas há um problema: não sabemos se 70% das tarefas do AssertIA são simples. Análise jurídica pode ter distribuição invertida — 70% complexa, 30% simples. Se for assim, o savings real cai para <20% antes de contabilizar overhead operacional do roteador.

Os 88% em GPT-4.1 podem significar duas coisas radicalmente diferentes: 1. Inércia de configuração — tudo vai pro frontier porque ninguém testou alternativa → routing tem valor alto 2. Complexidade genuína — as tarefas realmente precisam de frontier → routing tem valor marginal

Sem dados de complexidade por tarefa, não há como distinguir.

O que o Adversarial Ensinou (3 rounds)

Round 1 (heartbeat): GPT e Grok redirecionaram de "cost deflation wave" para "substituibilidade por workload". Aceito.

Round 2 (pre-report): Ambos convergiram: "solved problem" é falso — maturidade de ferramentas ≠ generalização econômica. Survivorship bias nos cases. Aceito e reframed.

Round 3 (consolidate-state): Crítica mais precisa: "complexidade" sozinha é insuficiente como métrica de routing. Em domínio jurídico, uma task lexicamente simples pode ser operacionalmente de alto risco. A recomendação de "4h para classificar 50-100 tasks" é subdimensionada e metodologicamente frágil sem definição operacional de complexidade.

Ponto forte do steelman (GPT): Em workload jurídico/regulado, o custo dominante não é token — é erro, inconsistência e falta de explicabilidade. Concentrar em frontier pode ser racional: reduz variância, simplifica auditoria, incident response e governança.

Ajuste incorporado: A recomendação mudou de "classificar por complexidade" para "profilear por 3 dimensões: complexidade, risco operacional e tolerância a erro". Sem essa tríade, routing é otimização prematura.

Conexão com o Trabalho

Este beat conecta com dois beats anteriores de hoje: - Quality Stack (beat anterior): HalluGraph/Contextual RAG/RRPO medem qualidade por tipo de tarefa — exatamente o dado que routing precisa para funcionar - Governança IA TCU (research): framework regulatório frágil do TCU aumenta risco de routing — sem classificação de risco formal, adicionar camada de decisão automatizada é governance debt

A recomendação não é "implementar routing". É: profilear uma amostra de 50-100 tasks do AssertIA em 3 dimensões — complexidade (simples/médio/frontier-hard), risco operacional (baixo/alto) e tolerância a erro (reversível/irreversível). Custo: ~8-12h de revisão humana (não 4h — adversarial corrigiu a estimativa). Valor: decide se R$19k/mês de economia é real ou ilusão, e em quais categorias routing seria seguro vs arriscado.

A pergunta que faltava no Brief #001

O Horizon Brief #001 trouxe 4 sinais — todos sobre como pagar menos. A revisão adversarial apontou o viés: zero sinais sobre como fazer melhor. Fui buscar o lado da qualidade.

Encontrei três ferramentas que não estavam no nosso radar. O valor não está em recomendar implementação (decisão técnica é domínio do roberto) — está em saber que existem. Se alguém perguntar "como vocês medem qualidade?", a resposta "não medimos" é diferente de "conhecemos X, Y e Z, e decidimos conscientemente que ainda não é prioridade."

As 3 ferramentas

1. HalluGraph — detecção de alucinação com trilha de auditoria

Paper: "HalluGraph: Auditable Hallucination Detection for Legal RAG Systems via Knowledge Graph Alignment" (Noël et al., arXiv:2512.01659, dez 2025, under review).

O conceito: extrair knowledge graphs do contexto, da query e da resposta, e medir o alinhamento estrutural entre eles. Dois scores: - Entity Grounding (EG): entidades na resposta aparecem nos documentos fonte? - Relation Preservation (RP): relações afirmadas na resposta são suportadas pelo contexto?

Resultados: AUC 0.979 em docs estruturados, ~0.89 em tarefas generativas legais. Supera BERTScore, BLEURT, BARTScore, SelfCheckGPT em legal domain.

O que importa para nós: não é o AUC — é a TRILHA DE AUDITORIA. HalluGraph não diz apenas "esta resposta pode estar errada". Diz "esta entidade não tem grounding" e "esta relação não é suportada pelo contexto". Isso é o que compliance e governance precisam: rastreabilidade da assertiva ao documento fonte.

Limitação crítica (adversarial): HalluGraph detecta substituição de entidades e relações quebradas. NÃO detecta erros de raciocínio jurídico — interpretação errada de uma norma, ponderação incorreta de precedentes, conclusão que não segue das premissas. Em legal-AI, erros de reasoning podem ser mais graves que substituição de entidades. Se o AssertIA erra mais por reasoning que por entity substitution, HalluGraph é ferramenta certa para o problema errado.

2. Contextual RAG — de ~60% para 88-92%

A Meterra publicou dados do próprio stack (2026): naive RAG (busca semântica simples + geração) atinge ~60% de accuracy. Ao adicionar 3 camadas, chega a 88-92%:

Caveat (adversarial): esses números são de domínio genérico (tech/produto). Legal-PT é diferente: documentos mais longos, hierarquia normativa, temporalidade, precedentes conflitantes. A direção provavelmente se mantém (hybrid search ajuda, reranking ajuda), mas os números mudam — e podem mudar para pior se o chunking não respeitar a estrutura do documento jurídico. Não tratar como transferíveis.

Para o AssertIA: a pergunta é "em que ponto do espectro 60-92% estamos?" Se o pipeline já usa hybrid search e reranking, o ganho marginal é baixo. Se usa naive RAG, o ganho potencial é enorme. Sem saber, qualquer recomendação é especulativa.

3. RRPO — reranker treinável que suporta português

Paper: "Optimizing RAG Rerankers with LLM Feedback via Reinforcement Learning" (Wu et al., arXiv:2604.02091, abr 2026, Nanjing University).

Formaliza reranking como MDP e otimiza via PPO com LLM como supervisor de reward. Base: gte-multilingual-reranker-base — que suporta português. Resultado: +1-2 F1 sobre baseline GTE, supera RankZephyr (7B) sendo muito menor.

Achado não óbvio: o reranker treinado com um LLM (Qwen-7B) transfere sem fine-tuning para qualquer outro LLM downstream — GPT-4o, Claude-3.5, Gemini-2.5, Llama-3.1. Propriedade "plug-and-play" que permite trocar o modelo gerador sem retreinar o reranker.

Para o AssertIA: se o pipeline um dia precisar de reranking otimizado para PT jurídico, a infraestrutura existe (base multilingual + RRPO). Custo marginal de +1-2 F1 é baixo em termos absolutos, mas em high-stakes jurídico, cada ponto de recall pode significar um precedente relevante recuperado.

Revisão adversarial

GPT-5.4 e Grok levantaram 3 correções incorporadas:

1. PL 2338 não prescreve stack técnico. O PL foca em classificação de risco, transparência, supervisão humana e governança. A ponte "PL 2338 → HalluGraph" é forçada. O que o PL exigiria é accountability e rastreabilidade, não AUC em benchmark. HalluGraph é uma ferramenta possível, não uma exigência regulatória.

2. Quality-before-cost é falsa dicotomia. Reduzir custo pode ser pré-condição para medir qualidade em escala. Se avaliação requer muitas queries, múltiplos modelos e verificadores, custo alto inviabiliza iteração. Otimizar ambos simultaneamente e iterativamente é mais realista que sequenciar.

3. Erro dominante pode não ser factual. Se o AssertIA falha mais por raciocínio jurídico incorreto, interpretação errada de normas ou ponderação de precedentes, o quality stack inteiro é solução para o problema errado. Nenhuma das 3 ferramentas resolve reasoning errors.

Recomendação

Mapear primeiro, investir depois. Antes de qualquer decisão sobre quality stack, o time precisa saber: - Onde o AssertIA erra? (entidades, retrieval, raciocínio) - Quanto erra por tipo de tarefa? - Qual erro tem maior impacto operacional?

Se o erro dominante é entity substitution → HalluGraph é relevante. Se é retrieval fraco → hybrid search + reranking. Se é reasoning → nenhuma ferramenta resolve automaticamente, e supervisão humana é a camada de controle.

Custo da inação: esses 3 papers existem. Quando a comunidade de legal-AI consolidar padrões de quality measurement (e vai — HalluGraph já está em OpenReview), quem não tiver baseline vai ficar atrás. Não urgente, mas o relógio está correndo.

Fontes

• Noël et al., "HalluGraph: Auditable Hallucination Detection for Legal RAG Systems via Knowledge Graph Alignment", arXiv:2512.01659, dez 2025
• Meterra, "RAG in 2026: Beyond Naive Retrieval", meterra.ai/blog/rag-technology-2026, 2026
• Wu et al., "Optimizing RAG Rerankers with LLM Feedback via Reinforcement Learning", arXiv:2604.02091, abr 2026
• Ribeiro et al., "JurisTCU: A Brazilian Portuguese Information Retrieval Dataset", Language Resources and Evaluation / Springer, 2025

O erro que eu propagava

Em três beats consecutivos, citei a "Resolução TCU 347/2022" como o framework de governança de IA do TCU. Estava errado.

A Resolução-TCU nº 347, de 12 de dezembro de 2022, define a estrutura, as competências e a distribuição das funções de confiança das unidades da Secretaria do TCU. É um ato organizacional — distribui cargos e responsabilidades entre as unidades. Não menciona inteligência artificial.

A conexão indireta existe: a Res. 347 define a Setid (Secretaria de TI e Evolução Digital), que abriga o NIA (Núcleo de Inteligência Artificial, criado pela Portaria-Setid 2/2023). Mas atribuir à 347 o papel de "framework de IA" é como dizer que o organograma de uma empresa é sua política de segurança.

Classe de erro: derivação sem verificação primária. Inferi o conteúdo da resolução a partir de referências secundárias e propagei a inferência como fato. Três beats amplificaram o erro antes de eu ler o documento.

O que realmente existe: governança de IA do TCU, camada por camada

Camada 1: Política de TI (Res. TCU 303/2018)

Resolução-TCU nº 303, de 28 de novembro de 2018 — Política de Governança e Gestão Digital e de Tecnologia da Informação. Framework geral de governança de TI, não específico para IA. Estabelece princípios e estrutura de decisão para tecnologia no tribunal.

Camada 2: Segurança da informação (Res. TCU 342/2022)

Resolução-TCU nº 342, de 28 de setembro de 2022 — Política Corporativa de Segurança da Informação (PCSI/TCU). O Guia de IA Generativa declara explicitamente: "As disposições da PCSI/TCU também se aplicam no uso de IA generativa." Esta é a base normativa mais forte que se aplica a IA — mas é uma política de segurança da informação, não uma política de IA.

Camada 3: Estrutura operacional (Portaria Setid 2/2023)

Portaria-Setid nº 2, de 17 de abril de 2023 — institui o NIA. Competências: 1. Recomendar, pesquisar, avaliar e fornecer soluções de IA 2. Orientar usuários sobre serviços de IA 3. Promover boas práticas e lições aprendidas 4. Prover soluções de mineração de dados, ML e NLP 5. Normatizar padrões de uso dos serviços de IA

O NIA tem mandato para "normatizar padrões" — ou seja, pode criar regulação mais específica. Não tenho evidência de que tenha feito isso além do Guia.

Camada 4: Orientação prática (Guia de IA Generativa, jul 2024)

7 páginas. Publicado em 1 de agosto de 2024. Apresentado por Rainério Leite (secretário da Setid).

O que o Guia contém: - Definições (IA generativa, LLM, alucinação, viés de modelo, viés de automação) - Ferramentas aprovadas: ChatTCU, CopilotTCU, Microsoft Copilot (Windows/365/Bing) - Boas práticas organizadas por 5 categorias de risco: 1. Vazamento de dados / incidentes de segurança 2. Confidencialidade de informações sigilosas 3. Violação de propriedade intelectual / transparência 4. Danos à reputação / viés 5. Alucinação - Diretrizes normativas (p. 6) - Referências: ISO/IEC 38507:2022, ISO/IEC 23894:2023, Singapore Model AI Gov Framework

O que o Guia NÃO contém: - Classificação formal de risco de sistemas de IA - Requisito de avaliação de impacto algorítmico - Requisitos de auditabilidade ou explicabilidade - Governança de modelos (seleção, avaliação, versionamento) - Mecanismos formais de supervisão humana (apenas "sempre avalie e revise") - Taxonomia dos 20+ sistemas de IA do TCU por nível de risco

Linguagem: predominantemente soft — "recomenda-se", "espera-se", "sugere-se", "aconselha-se", "orienta-se", "indica-se". Proibições hard são raras: - "É vedado o desenvolvimento de aplicativos de IA generativa para público externo que não sejam produzidos pela unidade executiva de TI" - Violações por terceiros = possível quebra de contrato - Incidentes = tratados via PCSI (processo de resposta a incidentes)

Referências normativas citadas pelo Guia (lista completa)

Nota: Resolução TCU 347/2022 NÃO é citada em nenhum lugar do Guia.

O que isso significa para o AssertIA

1. Regime atual (soft). O consórcio opera sob o Guia de IA Generativa como terceiro contratado. As obrigações são: não inserir dados confidenciais em plataformas não aprovadas, revisar outputs, seguir PCSI. Violações = potencial quebra de contrato. É um regime leve para um sistema que analisa jurisprudência e auxilia decisões de auditoria.

2. Regime futuro (PL 2338). Se/quando o PL 2338 for aprovado: - Sistemas de IA que auxiliam decisões em contexto judicial/administrativo são candidatos a alto risco - Alto risco → avaliação de impacto obrigatória, transparência, supervisão humana formal - O gap entre o regime atual (orientativo) e o futuro (prescritivo) é significativo

3. Questão de proporcionalidade. A crítica adversarial é válida: ausência de codificação formal não significa necessariamente ausência de controles. Podem existir processos internos, checklists por sistema, DPIAs/LGPD que não são públicos. Mas para o consórcio, o que importa é a governança publicada — é isso que define as obrigações contratuais.

4. Ironia institucional matizada. O TCU auditou 292 órgãos federais em AI maturity (TC 006.662/2021-8) e recomendou "parâmetros e riscos para gestão de IA". Sua própria governança interna é orientativa. Isso não é necessariamente incoerente — o papel do TCU é controle externo, não autocontrole — mas cria uma vulnerabilidade de posicionamento quando o PL 2338 nivelar o campo.

Gap fechado e gaps novos

Fechado: "Texto completo da Resolução TCU 347/2022 não acessado" → Acessado e identificado como norma organizacional, não de IA. Framework real mapeado.

Novos gaps abertos: - Texto integral da Res. TCU 342/2022 (PCSI) — aplicável a IA mas conteúdo específico desconhecido - Portaria SEINC 2/2025 e Portaria Setid 1/2025 — aparecem em buscas sobre IA no TCU, conteúdo desconhecido (pode haver atualização recente) - Controles operacionais internos do TCU para IA — existem? Quais? - Classificação de risco dos 20+ sistemas do TCU — nenhum documento público faz essa taxonomia

AIUC-1: o padrão que ninguém no AssertIA está acompanhando

O que está acontecendo lá fora

Em 9 de março de 2026, a UiPath se tornou a primeira empresa a obter a certificação AIUC-1 — o primeiro padrão independente do mundo para segurança e confiabilidade de agentes de IA. Semanas depois, a Intercom obteve a mesma certificação.

Minha primeira reação: mais um selo corporativo. Mas ao derivar o que o padrão exige, a conclusão mudou.

Derivando: o que AIUC-1 realmente avalia

AIUC-1 não é um framework de governança como ISO 42001 (que é gestão: políticas, PDCA, documentação). AIUC-1 é teste técnico adversarial:

• 50+ salvaguardas técnicas, operacionais e legais que precisam estar implementadas
• 1000+ cenários de teste adversarial executados por auditor independente (Schellman, maior auditor de cybersecurity)
• Testes específicos: alucinação, tool misuse (agente excedendo limites), data leakage, prompt injection, brand risk
• Trimestral: o certificado é válido por 12 meses, mas re-teste acontece a cada 3 meses

A parte que me chamou atenção: AIUC-1 não foi criado por um vendor. Foi fundado por pessoas da Anthropic, desenvolvido com Orrick (escritório de advocacia), Stanford, Cloud Security Alliance, MIT e MITRE. É um consórcio acadêmico-indústria — o tipo de iniciativa que tende a ganhar tração porque não compete com ninguém.

O stack de quality assurance que está se cristalizando

Tentei derivar como os padrões se encaixam, e emergiu uma estrutura em 3 camadas:

O que me surpreendeu: as 3 camadas já existem. Não é futuro. ISO 42001 está publicado desde 2023. AIUC-1 desde março. EU AI Act em vigor parcial. PL 2338 na Câmara.

Gap inline: mas qual a cobertura do AssertIA contra essas 3 camadas? Minha hipótese: zero. A Resolução TCU 347/2022 pode cobrir parte da camada 3, mas não sei se ela trata de teste adversarial ou medição de alucinação. Esse é um gap que preciso verificar — se a 347 já cobre, o risco é menor do que estou estimando.

Por que isso importa AGORA (não daqui a 2 anos)

O precedente é ISO 27001 para segurança da informação. Quando surgiu, era "nice to have". Em 5 anos, virou requisito de facto em compras públicas de TI. O padrão em si não era obrigatório — mas os editais passaram a exigi-lo.

Se PL 2338 classificar o AssertIA como sistema de alto risco (plausível — análise de processos judiciais com recomendação automática), avaliação de impacto vira obrigação legal. E o mercado já tem um benchmark técnico contra o qual medir: AIUC-1.

O custo de implementar governança retroativamente (documentar, testar, certificar) é ordens de magnitude maior que incorporar enquanto o sistema está sendo construído.

Contexto complementar: Learned Hand e a produtização de AI judicial

Paralelamente, a startup Learned Hand está pilotando ferramentas de IA para juízes em 10+ tribunais estaduais nos EUA, incluindo a LA Superior Court e a Michigan Supreme Court. Thomson Reuters e LexisNexis têm contratos com o judiciário federal. O padrão de qualidade que esses produtos definem cria expectativas que se propagam — quando um juiz pergunta "por que a ferramenta do TCU não faz o que o Learned Hand faz?", a resposta precisa existir.

Gap inline: a jurisdição é diferente (common law vs civil law, judiciário vs tribunal de contas). O mecanismo de propagação é mais institucional que técnico — tribunais se observam e copiam. Mas a velocidade dessa propagação para o Brasil é incerta.

Recomendação

Acompanhar. Mapear o gap do AssertIA contra as 3 camadas do stack (ISO 42001 + AIUC-1 + Res. TCU 347). Se a 347 já cobre teste de confiabilidade, o risco é gerenciável. Se não cobre — e minha hipótese é que não — o time precisa saber disso antes do próximo ciclo de renovação contratual.

Custo da inação

Se o PL 2338 avança e classifica AssertIA como alto risco, o time será pego sem framework de avaliação de impacto, sem baseline de medição de alucinação (gap do beat #4), e sem governança documentada. A defesa retroativa custará meses. O custo de começar agora: um mapeamento de 2-3 dias contra os critérios do AIUC-1.

A derivacao

Comecei tentando entender: por que o TCDF conseguiu comprar Google e Microsoft em semanas, enquanto o AssertIA esta no ciclo 71 de um contrato que comecou em 2022?

Minha hipotese inicial: sao instrumentos de contratacao diferentes, e isso explica a velocidade. O TCDF comprou um produto de prateleira (SaaS); o TCU encomendou algo que nao existia.

Derivando: no Brasil, contratacao publica tem varias vias. Pregao para bens comuns. Concorrencia para contratos complexos. Inexigibilidade quando so um fornecedor atende. E a Encomenda Tecnologica (ETEC) para P&D com risco tecnologico.

O AssertIA se encaixa perfeitamente na ETEC: o TCU queria um modulo de instrucao assistida por IA que nao existia no mercado. Emitiu um chamado publico (procedimento pre-contratual, nao licitacao), recebeu 18 propostas, selecionou NeuralMind-Terranova. Contrato 20/2023.

A pesquisa confirmou: e exatamente isso.

O mecanismo e suas implicacoes

A ETEC esta na Lei 10.973/2004, Art. 20. O ponto que chamou minha atencao: o paragrafo 4 permite que, ao final da ETEC, o fornecimento do produto resultante seja contratado por dispensa de licitacao — inclusive com o proprio desenvolvedor.

Isso e potencialmente uma trilha de transicao embutida: se o AssertIA produz um "produto" funcional, o TCU poderia contratar seu fornecimento sem nova licitacao.

Mas a revisao adversarial cortou meu excesso de confianca em dois pontos:

1. par.4 e faculdade legal, nao mecanismo operacional. "Pode haver dispensa" nao significa "ha caminho desimpedido." Requer previsao contratual explicita, demonstracao de exclusividade, economicidade, e que o resultado seja um "produto" delimitado — nao um servico continuo.

2. IA nao se comporta como produto discreto. O par.4 foi desenhado para tecnologias que resultam em um entregavel acabado (prototipo, patente, processo industrial). IA em producao requer dados continuos, atualizacao de modelos, infraestrutura cloud, manutencao. Se AssertIA e mais "servico" do que "produto", o par.4 perde tracao.

Como o TCDF comprou

O TCDF anunciou em fevereiro de 2026 a adocao de Google Agentspace (Gemini Enterprise), NotebookLM e Microsoft Copilot — ~500 licencas.

Nao encontrei documentacao publica do contrato (portal com erro SSL, DODF timeout). Mas o padrao no setor publico brasileiro e:

• Google: inexigibilidade (Art. 74, Lei 14.133) via revendedor autorizado (padrao TJ-AM, outros orgaos)
• Microsoft: pregao eletronico ou adesao a ata de registro de precos, possivelmente usando referencial do acordo MGI-Microsoft (ampliado em mar 2026)

A velocidade e radicalmente diferente: inexigibilidade para SaaS pode ser formalizada em semanas. ETEC para P&D leva meses so para o chamamento publico.

O argumento Pahlka: procurement como Maslow

Jennifer Pahlka publicou em 5 de abril de 2026 o artigo "Yes, philanthropy should fund AI in government" (Eating Policy). O argumento central: procurement esta na base da piramide de necessidades de governo — sem reforma de procurement, frameworks de governanca nao saem do papel.

Tres pontos que conectam com o AssertIA:

1. Soberania vs dependencia. A distincao critica nao e build vs buy, mas se a contratacao aumenta a capacidade soberana do orgao ou aprofunda dependencia de vendor. ETEC (build) constroi capacidade; off-the-shelf (buy) cria dependencia.

2. Normas sobre quem pode tocar no sistema. Pahlka nota que ferramentas de coding agentivo (como Claude) poderiam permitir que gestores governamentais corrijam bugs e construam modulos. Mas a barreira e "normas sobre quem tem permissao de tocar um sistema" — nao capacidade tecnica.

3. Especificidade mata velocidade. No setor publico, quanto mais especifica a necessidade, mais lento o procurement. O TCDF comprou rapido porque comprou generico. O TCU foi lento porque encomendou algo especifico.

A literatura academica reforça: Mulligan (2019) argumenta que procurement e de facto governanca de IA. Johnson et al (FAccT 2025) mostram empiricamente que vendors escondem informacao critica citando propriedade intelectual, e cidades ficam sem leverage pos-contratacao.

O que isso significa para a renovacao

A questao nao e se o AssertIA deveria ter sido comprado pronto (como o TCDF fez). Em 2022, nao havia Google Agentspace. A ETEC era o unico caminho para profundidade de dominio.

A questao e: o instrumento contratual (ETEC) previu explicitamente a transicao para fornecimento operacional? Se sim, o par.4 e um trunfo. Se nao, a renovacao exige novo instrumento — e ai a velocidade do off-the-shelf vira argumento competitivo.

Tres coisas que eu nao sei e que determinam o rumo:

1. O que diz o contrato original sobre transicao? Cabe ao operador verificar se o Chamado Publico/contrato tem clausula prevendo par.4.

2. AssertIA e produto ou servico? Se e um modulo entregavel (software instalavel, API documentada, corpus processado), par.4 se aplica. Se e operacao continua (pipeline que requer atualizacao de modelos, curadoria de dados, evolucao de prompts), e servico — e precisa de outro instrumento.

3. Quem detém a propriedade intelectual? Par.1 do Art. 20 define que criacoes desenvolvidas durante o contrato pertencem ao periodo. Se o consorcio detem a PI, o TCU fica dependente. Se o TCU detem, pode internalizar ou licitar novo fornecedor.

Revisao adversarial

GPT-5.4: "Voce esta confundindo base normativa para dispensa com capacidade real de converter P&D em servico operacional de IA no setor publico." Valido — ajustei de "caminho embutido" para "potencial caminho que requer verificacao contratual."

Grok: "A analise ignora que procurement e governance sao inseparaveis. Sem oversight tecnico, definicao de requisitos e accountability continua, nenhuma mecanica legal resolve dependencia tecnologica." Parcialmente valido — a formulacao "procurement vs governance" e falsa dicotomia; o ponto correto e que ambos sao necessarios, mas procurement determina o que e possivel.

A pergunta

O AssertIA gasta ~R$30 mil/mês em API do GPT-4.1. Modelos open source (Llama, Qwen, Mistral, DeepSeek) permitem treinar um modelo próprio. Vale a pena?

O que encontrei

Fine-tuning é barato de treinar, caro de operar

Com QLoRA, treinar um modelo de 7B parâmetros custa R$5-R$250 por rodada. Um ciclo completo (dados + 15 rodadas + avaliação + implantação) sai por ~R$18k. A barreira não é compute — é preparação de dados de qualidade e avaliação rigorosa.

Mas servir esse modelo em produção 24/7 com confiabilidade institucional (SLA, fallback, monitoramento) é outra história. A literatura sugere multiplicar custos de GPU por 1.5-2x, e em contexto governamental pode ser mais.

Quem já fez

AuditWen (China, 2024) — caso mais relevante. Fine-tuned de Qwen 7B com 30k exemplos de auditoria. Superou modelos genéricos em 15 tarefas. Publicado em CCL 2024 e FinNLP 2025.

Juru (Brasil, 2024) — fine-tuned de Sabiá-2 para direito brasileiro. Melhorou na OAB e ENADE, mas piorou em conhecimento geral. Catastrophic forgetting documentado.

SaulLM (Edinburgh, NeurIPS 2024) — fine-tuned de Mistral para direito (inglês). Estado da arte em LegalBench. Usou dados sintéticos.

PRUMe AI (Brasil, 2025) — RAG com explicabilidade para controle externo. 89% de consistência sem fine-tuning. Mostra que RAG bem feito pode ser suficiente.

Qwen > Llama para português

No benchmark PoETa v2, Qwen 2.5 7B supera Llama 3.1 8B por ~10 pontos. Para fine-tuning em PT jurídico, Qwen 2.5 é a melhor base open-weight.

Sabiá-4 (Maritaca AI) é nativo em PT-BR e treinado em legislação brasileira — mas é proprietário (API). Vale investigar como alternativa direta ao GPT-4.1.

O que a revisão adversarial encontrou

GPT-5.4 e Grok-4.20 concordaram: sem dados reais de distribuição de workload do AssertIA, toda estimativa de economia é especulativa. Benchmarks genéricos não transferem para tarefas específicas do TCU. E o estudo da UC Berkeley (86% vs 75%) é em domínio agrícola, não jurídico.

Recomendação

Estratégia gradual em duas fases:

Fase 1 (agora): Roteamento de modelos — enviar tarefas simples para modelos baratos (Gemini Flash, GPT-4.1 nano). Economia estimada de 60-80%. Sem risco, sem fine-tuning, reversível em horas.

Fase 2 (mês 2-4): Piloto de fine-tuning na tarefa de maior volume, com avaliação rigorosa. Decisão go/no-go baseada em dados reais, não em benchmarks genéricos.

Pré-requisito para ambas: levantar distribuição de custo por tarefa no pipeline. Sem esse dado, nenhuma decisão tem base.

Gaps abertos

1. Distribuição de custo por tarefa no AssertIA
2. Benchmark de modelos em tarefas específicas do TCU
3. Inventário de hardware do NIA
4. Custo operacional real de servir modelo em produção no contexto TCU
5. Avaliação da Sabiá-4 como alternativa ao GPT-4.1

O que encontrei

Cruzando 4 transcrições (reunião AssertIA 04/07, P.O. 03/27, dailies 04/01 e 04/02), a formalização de criação de agentes no AssertIA está emergindo em 4 camadas simultâneas — nem todas explícitas para todos os envolvidos.

Camada 1: Técnica — Editor de Workflow

Luís Emídio está construindo um editor visual de fluxos de trabalho usando React Flow. Cada nó é um agente ou humano, com transições configuráveis. O editor gera um dicionário JSON com as configurações. PR em rascunho desde 04/01 (área de código nova, refatoração em andamento). Gilmar está implementando controle de acesso separadamente.

Gap crítico: Pedro perguntou (04/02) se é possível reusar agentes entre salas. Resposta: não, só duplicar. Isso limita a escalabilidade e cria drift entre cópias do mesmo agente.

Camada 2: Governança — P.O. como Filtro

O Núcleo de Dados (Larissa, Solange, Guilherme Braga) foi designado P.O. pela secretária da CJUS (formalizado 03/26). Papel: filtrar o que é implementado, gerenciar expectativas de usuários. Lucas explora e cria, mas deve mostrar ao Núcleo antes de ir para o usuário.

Na reunião de hoje (04/07), Larissa reforçou: "vai facilitar descrever o que cada usuário tem que fazer quando quiser uma coisa nova" e enfatizou co-responsabilidade do usuário com a solução.

Camada 3: Organizacional — Documentação de Estrutura

Roberto pediu (03/27) formalização escrita das divisões do TCU sendo atendidas. Guilherme Braga sugeriu organograma da CJUS. Status: incerto se foi produzido.

Camada 4: Curadoria de Conteúdo

Lucas (04/07) explicou que os agentes dependem de buscas RAG (jurisprudência + instruções passadas) e que essas buscas precisam de manutenção contínua. "A gente implementou e nunca mais olhou para trás" — agora está revisando. Função da curadoria de conteúdo é ortogonal à criação de agentes mas igualmente crítica.

O que não está no radar (gaps)

1. Processo escrito não existe: a governança é oral e relacional. O P.O. filtra por conversa, não por documento. Quando o contrato terminar, esse conhecimento se perde.
2. Validação de agentes: testes são manuais, por usuários. Não há avaliação sistemática (métricas, amostras estatísticas, comparação de versões).
3. Ciclo de vida: nenhuma menção a deprecação, versionamento, ou monitoramento contínuo de agentes em produção.
4. Reuso vs duplicação: sem catálogo de agentes reutilizáveis, cada sala recria do zero. Drift inevitável.

Implicação para handover

A formalização em 4 camadas é positiva, mas as camadas 2 (governança) e 3 (organizacional) dependem de pessoas específicas. Se o Núcleo de Dados ou o Lucas saírem, o processo desmorona. Documentar o processo — não só as divisões — é o que torna o handover viável.

O sinal

Em fevereiro de 2026, o Tribunal de Contas do DF anunciou a adocao de Google Agentspace (com Gemini Enterprise), NotebookLM e Microsoft Copilot. Sao ~500 licencas distribuidas entre setores. Auditores usarao Agentspace para inspecoes e analise de licitacoes; funcionarios em geral usarao Copilot para fluxos de documentos.

A escolha e significativa nao pelo que o TCDF comprou, mas porque comprou. Em 2023, quando o TCU lancou ChatTCU, APIs enterprise de IA generativa nao existiam na forma atual. Google Agentspace foi anunciado em 2024, disponivel comercialmente em 2025. O TCDF fez uma escolha que so existe agora.

O que muda para AssertIA

Nao e uma bifurcacao BUY vs BUILD — e uma evolucao de opcoes. Mas o efeito pratico e real: um tribunal par agora tem 500 licencas de ferramentas de IA rodando, enquanto AssertIA ainda esta em ciclos de desenvolvimento contratual. A pergunta que um decisor vai fazer: "se o TCDF resolveu com Google e Microsoft, por que precisamos de um consorcio externo?"

A resposta deveria ser: profundidade de dominio. ChatTCU e generalista (suporte a auditoria, 2.700 usuarios, 90% da forca de trabalho). Google Agentspace e horizontal (analise documental, cruzamento de dados). AssertIA faz analise de jurisprudencia especifica — nuggets, classificacao de acordaos, busca semantica em corpus juridico do TCU.

Mas essa resposta so funciona se estiver articulada e demonstrada. Hoje, nao sei afirmar com precisao o que AssertIA faz que ChatTCU + Agentspace nao fazem.

Outros sinais do ecossistema

• TCE-MT lancou a plataforma "Platao" para fiscalizacao, mas sem dados de escala ou escopo (pode ser piloto de 5 pessoas ou operacao robusta).
• MIT Tech Review reporta que "60% dos tribunais de contas brasileiros implementaram solucoes de IA" — dado sem metodologia, portanto sem peso analitico. O que conta como "solucao de IA"?
• OECD (abr 2024) reconheceu o TCU como unica entidade governamental em estagio avancado de IA generativa. Isso posiciona o TCU como referencia internacional, mas a narrativa e centrada em ChatTCU, nao em AssertIA.
• INTOSAI Journal publicou artigo sobre como o TCU exerceu independencia para abordar desafios de IA. Menciona ChatTCU extensivamente, regulacao de IA (PL 2338), e transferencia de tecnologia para Honduras e Chile.

Revisao adversarial (7 objecoes, 4 critical)

Submetido a review via subagent (Claude Sonnet — edge-consult indisponivel). Principais correcoes incorporadas:

1. A dicotomia BUY vs BUILD pode ser artefato temporal, nao estrategia. TCU construiu porque precisou em 2023; TCDF comprou porque pode em 2026. Incorporado — reframe como evolucao, nao bifurcacao.
2. ChatTCU ja era conhecido pelo operador. O dado novo nao e a existencia, mas o numero: 90% da forca de trabalho como usuarios ativos, e o reconhecimento OECD. Ajustado.
3. "60% de adocao" sem metodologia nao tem peso analitico. Concordo — qualificado como dado nao verificado.
4. Gap critico: sem articular o que AssertIA faz de especifico, a tese de "profundidade" e vazia. Aceito — este e o gap mais importante que este beat abre.

Gaps abertos

• O que AssertIA faz que ChatTCU + Agentspace nao fazem? (gap critico — precisa de resposta antes da renovacao)
• Custo comparativo: ChatTCU (infra + pessoal interno) vs TCDF (500 licencas vendor) vs AssertIA (ciclos contratuais)
• Data exata do contrato TCDF — fev 2026 e anuncio, assinatura ou inicio de uso?
• TCE-MT Platao — escala e escopo reais
• Goodhart's Law em evaluation — sinal lateral do X que conecta com trabalho de avaliacao do roberto