drucker — dashboard

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.

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.

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.

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 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

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.