Framework de relatórios com IA: da automação à governança de conhecimento

No primeiro artigo desta série (https://adrock.com.br/blog/automacao-relatorios-seo-ia-arquitetura-conhecimento), mostramos como a Ad Rock começou a transformar um processo tradicional de relatórios de SEO em uma plataforma inteligente de análise, capaz de correlacionar dados, preservar histórico e gerar relatórios executivos com apoio de inteligência artificial.

Aquela primeira arquitetura nasceu de uma necessidade concreta: reduzir o trabalho operacional envolvido na leitura mensal de dezenas de relatórios de Google Analytics 4, Google Search Console e SEMrush.

O sistema funcionou.

Mais importante do que isso, ele revelou quais elementos realmente determinam a qualidade de uma análise automatizada.

Não basta conectar uma IA a um conjunto de PDFs.

Não basta criar um prompt extenso.

Também não basta pedir que o modelo resuma cada ferramenta.

A qualidade do resultado depende de arquitetura, contexto, governança, rastreabilidade, separação de responsabilidades e memória controlada.

Com base nesses aprendizados, começamos a desenvolver a segunda geração do framework.

Desta vez, o objetivo não era apenas adaptar o sistema anterior para outro cliente.

O objetivo era transformar a experiência acumulada em uma arquitetura reutilizável para projetos de SEO, Analytics, Google Ads e estratégia digital.

Da primeira implementação para um framework reutilizável

A primeira versão foi criada para um projeto internacional de SEO com grande volume de relatórios técnicos.

Ela resolveu questões importantes:

• organização mensal por competência;

• separação entre dados originais e análises;

• geração de relatórios intermediários em Markdown;

• consolidação de um resumo executivo;

• uso de histórico para comparação;

• revisão humana antes do encerramento;

• atualização da memória somente após aprovação.

Ao iniciar um segundo projeto, percebemos que simplesmente duplicar o repositório e trocar o nome do cliente seria um erro.

Cada operação possui fontes, objetivos, indicadores, públicos, eventos, canais e critérios de decisão diferentes.

O novo projeto precisava analisar quatro frentes obrigatórias:

1. Google Analytics 4

2. Google Ads

3. Google Search Console

4. SEMrush

O sistema anterior tinha sido criado principalmente para SEO e Analytics.

A nova arquitetura precisava incorporar mídia paga como uma camada de primeira classe, com regras específicas para campanhas, grupos de anúncios, palavras-chave, termos de pesquisa, conversões, CPA, CTR, ROAS, demanda e sazonalidade.

Foi nesse momento que o projeto deixou de ser apenas uma automação especializada e começou a se tornar um framework.

A principal evolução: separar arquitetura, inteligência e conhecimento

Uma das maiores limitações de sistemas baseados somente em prompts é a concentração excessiva de responsabilidades.

Um único prompt acaba tentando definir:

• o que analisar;

• como interpretar;

• como escrever;

• como usar histórico;

• como tratar hipóteses;

• como priorizar ações;

• como produzir o relatório final.

Isso cria documentos longos, difíceis de manter e propensos a contradições.

Na segunda geração, dividimos o sistema em três grandes camadas.

Camada estrutural

A camada estrutural define como o projeto funciona.

Ela inclui documentos responsáveis por:

• arquitetura do repositório;

• preparação da competência mensal;

• validação dos arquivos;

• controle do fluxo;

• interrupções obrigatórias;

• responsabilidades do Codex;

• responsabilidades do ChatGPT;

• critérios de conclusão;

• política de versionamento.

Entre os principais documentos estão:

• especificação mestre;

• README técnico;

• orquestrador operacional;

• comando mensal;

• controlador de execução.

Essa camada não ensina a IA a analisar dados.

Ela garante que o processo seja executado corretamente.

Camada cognitiva

A camada cognitiva define como a análise deve ser realizada.

Ela foi separada em documentos especializados:

• estilo de escrita;

• regras de análise;

• glossário oficial;

• governança da memória;

• hipóteses e níveis de confiança;

• estilo consultivo;

• estrutura do relatório executivo.

Cada documento possui uma responsabilidade clara.

O arquivo de estilo de escrita define como o texto deve soar.

As regras de análise definem como as métricas devem ser correlacionadas.

O glossário define como o framework interpreta conceitos como crescimento consistente, eficiência, demanda, estabilidade, recuperação e deterioração.

O documento de hipóteses define como lidar com incerteza.

O estilo consultivo define como transformar dados em recomendações.

O documento do relatório executivo define a forma final da entrega.

Essa separação reduz duplicações e facilita a manutenção.

Quando uma regra muda, sabemos exatamente qual documento deve ser atualizado.

Camada de conhecimento permanente

A terceira camada guarda aquilo que é específico do projeto e do cliente.

Ela inclui documentos sobre:

• contexto institucional;

• públicos e países;

• relatórios utilizados;

• indicadores;

• objetivos;

• decisões arquiteturais;

• boas práticas;

• lições aprendidas;

• mudanças estruturais.

Essa camada diferencia o framework genérico da implementação especializada.

A arquitetura pode ser reutilizada em vários projetos.

O conhecimento muda conforme o cliente.

Essa separação permite imaginar diferentes implementações baseadas na mesma estrutura:

• um projeto focado em portais jornalísticos;

• um projeto educacional internacional;

• um projeto de mídia paga;

• um projeto institucional;

• um projeto de organizações sem fins lucrativos;

• um projeto de e-commerce.

O núcleo permanece estável.

A base de conhecimento adapta o comportamento.

Um controlador em vez de um prompt monolítico

Outra evolução importante foi redefinir o papel do prompt principal.

Na primeira geração, o prompt mestre concentrava muitas regras.

Na nova arquitetura, ele funciona como um controlador de execução.

Sua função é:

• carregar os documentos na ordem correta;

• validar os pré-requisitos;

• confirmar a competência ativa;

• validar as fontes obrigatórias;

• acionar os prompts especializados;

• gerar as análises individuais;

• validar a consistência;

• gerar o resumo executivo;

• interromper para revisão humana.

Ele não redefine métricas.

Não ensina estilo.

Não armazena histórico.

Não decide sozinho como interpretar posição média, CTR, conversão ou sazonalidade.

Essas responsabilidades pertencem às outras camadas.

O resultado é um prompt principal menor, mais previsível e mais fácil de auditar.

Competências mensais autocontidas

Cada período analisado possui uma estrutura independente.

Um exemplo simplificado:

reports/
└── AAAA-MM/
    ├── source/
    ├── analysis/
    │   ├── ga4_analise.md
    │   ├── google_ads_analise.md
    │   ├── gsc_analise.md
    │   └── semrush_analise.md
    ├── output/
    │   └── resumo_executivo.md
    └── manifest.json

reports/
└── AAAA-MM/
    ├── source/
    ├── analysis/
    │   ├── ga4_analise.md
    │   ├── google_ads_analise.md
    │   ├── gsc_analise.md
    │   └── semrush_analise.md
    ├── output/
    │   └── resumo_executivo.md
    └── manifest.json

reports/
└── AAAA-MM/
    ├── source/
    ├── analysis/
    │   ├── ga4_analise.md
    │   ├── google_ads_analise.md
    │   ├── gsc_analise.md
    │   └── semrush_analise.md
    ├── output/
    │   └── resumo_executivo.md
    └── manifest.json

Essa organização resolve problemas comuns em fluxos manuais:

• arquivos de meses diferentes misturados;

• períodos comparativos incorretos;

• relatórios duplicados;

• perda da origem de uma conclusão;

• análises geradas com fontes ausentes;

• dificuldade de reconstruir decisões antigas.

Cada competência deve ser autocontida.

Os dados atuais ficam no mês atual.

O histórico é usado apenas como contexto.

O manifesto como contrato da competência

O manifest.json deixou de ser apenas uma lista de arquivos.

Ele passou a funcionar como contrato operacional do período.

O manifesto registra:

• competência;

• status;

• fontes identificadas;

• arquivos utilizados;

• tipo de cada arquivo;

• período;

• observações;

• análises geradas;

• resumo executivo;

• revisão humana;

• encerramento.

Antes de qualquer análise, o sistema valida o manifesto.

Se uma fonte obrigatória estiver ausente, o fluxo é interrompido.

Se houver mistura de períodos, o fluxo é interrompido.

Se um arquivo estiver ilegível, o sistema não inventa o dado.

Essa regra parece simples, mas é fundamental para evitar relatórios convincentes baseados em entradas incompletas.

Quatro análises obrigatórias antes da consolidação

Na segunda geração, o resumo executivo não é gerado diretamente a partir dos PDFs.

Antes dele, são produzidas quatro análises técnicas:

Google Analytics 4

A análise cobre audiência, sessões, usuários, canais, páginas, eventos, engajamento, países, cidades e dispositivos.

Também considera eventos personalizados e possíveis anomalias de mensuração.

Google Ads

A análise avalia campanhas, grupos, anúncios, palavras-chave, conversões, CPA, CTR, CPC, custo, ROAS, dispositivos, demanda e sazonalidade.

Uma das regras mais importantes é não interpretar uma queda isolada como deterioração estrutural.

Antes de sugerir mudanças amplas, o sistema precisa verificar:

• histórico dos meses anteriores;

• volume de impressões;

• procura disponível;

• campanhas responsáveis;

• grupos responsáveis;

• comportamento pós-clique;

• alterações de conversão.

Google Search Console

A análise correlaciona cliques, impressões, CTR, posição média, páginas, consultas, países e dispositivos.

O framework registra explicitamente que posição média menor representa melhora e posição média maior representa piora.

Essa regra existe porque ferramentas podem exibir percentuais, setas e cores de maneira ambígua.

Os valores absolutos sempre precisam ser conferidos.

SEMrush

O SEMrush passou a ser uma fonte obrigatória separada.

O sistema diferencia:

• comparação mensal;

• gráfico anual;

• desktop;

• mobile;

• dados reais integrados;

• estimativas proprietárias;

• monitoramento de posição;

• backlinks;

• autoridade;

• auditoria técnica.

Uma regra permanente impede que gráficos anuais sejam utilizados como substitutos do comparativo entre o mês atual e o mês anterior.

Volume e eficiência não são a mesma coisa

A nova arquitetura trata volume e eficiência como dimensões diferentes.

Alguns exemplos:

• mais impressões não significam melhor desempenho se os cliques não acompanharem;

• menos impressões com CTR maior podem representar menor alcance com melhor eficiência;

• mais usuários com menor engajamento podem indicar expansão de audiência com consumo mais superficial;

• mais cliques com menor taxa de conversão podem indicar pior qualidade pós-clique;

• posição média melhor com queda de tráfego pode indicar redução de demanda;

• custo menor com queda proporcionalmente maior de conversões representa perda de eficiência.

Esse tipo de distinção impede conclusões superficiais.

O sistema não classifica automaticamente uma alta como positiva ou uma queda como negativa.

Ele procura entender qual dimensão mudou e qual impacto essa mudança produz.

A governança das hipóteses

Sistemas de IA tendem a completar lacunas com explicações plausíveis.

Em reporting, isso é perigoso.

Por isso, criamos uma política formal para hipóteses e níveis de confiança.

As interpretações são classificadas internamente em níveis como:

• confiança muito alta;

• confiança alta;

• confiança moderada;

• confiança baixa;

• confiança muito baixa.

Uma conclusão possui maior confiança quando:

• duas ou mais fontes independentes convergem;

• os valores são consistentes;

• não existem sinais relevantes em sentido contrário;

• o histórico confirma o comportamento.

Quando há apenas uma evidência isolada, o sistema deve usar linguagem proporcional.

Em vez de afirmar:

A queda aconteceu por sazonalidade.

A análise pode registrar:

A redução pode estar associada à menor procura do período, mas a hipótese precisa ser confirmada com o histórico das consultas e os próximos ciclos.

A transparência é mais valiosa do que a falsa certeza.

A memória deixou de ser um arquivo e passou a ter governança

Na primeira geração, já existia histórico.

Na segunda, criamos um ciclo de vida formal para o conhecimento.

A arquitetura diferencia:

History

Guarda o que aconteceu em cada competência.

Inclui:

• fatos aprovados;

• indicadores;

• hipóteses;

• recomendações;

• pendências;

• itens para acompanhamento.

Knowledge

Guarda conhecimentos permanentes.

Inclui:

• contexto institucional;

• características do portal;

• regras metodológicas;

• limitações conhecidas;

• decisões estruturais;

• aprendizados reutilizáveis.

Um resultado mensal não pode ser promovido automaticamente para conhecimento permanente.

Para isso, ele precisa atender critérios como:

• recorrência em múltiplas competências;

• relevância metodológica;

• decisão estrutural aprovada;

• limitação conhecida da ferramenta;

• comportamento confirmado ao longo do projeto.

Também criamos regras para obsolescência.

Conhecimento permanente precisa ser revisado ou removido quando:

• a estratégia muda;

• uma ferramenta é substituída;

• a metodologia evolui;

• novas evidências contradizem uma regra anterior;

• um processo é descontinuado.

A memória do sistema não deve apenas crescer.

Ela precisa permanecer válida.

Revisão humana como barreira de qualidade

A automação continua possuindo duas interrupções obrigatórias.

A primeira ocorre antes da análise, quando o sistema solicita os arquivos da competência.

A segunda ocorre após a geração das análises e do resumo executivo.

Nesse momento, o framework aguarda aprovação humana.

Antes da aprovação, ele não pode:

• atualizar o histórico;

• promover conhecimento;

• marcar a competência como concluída;

• gerar os documentos finais;

• transformar uma hipótese preliminar em memória permanente.

A revisão humana valida:

• números;

• interpretação;

• proporcionalidade;

• contexto editorial;

• recomendações;

• linguagem final.

A inteligência artificial acelera a organização e a análise.

A responsabilidade final permanece humana.

Privacidade e política de versionamento

Outro aprendizado da segunda geração foi separar o que deve e o que não deve ir para o Git.

O repositório armazena:

• arquitetura;

• prompts;

• conhecimento;

• histórico aprovado;

• arquivos Markdown;

• manifestos;

• templates;

• scripts.

Não são versionados:

• PDFs originais;

• arquivos enviados pelo cliente;

• DOCX finais;

• PDFs finais;

• arquivos temporários;

• materiais brutos de entrada.

A pasta source/ permanece exclusivamente local.

Isso reduz riscos de exposição de dados, evita crescimento desnecessário do repositório e preserva o Git como base de inteligência e governança, não como arquivo de documentos do cliente.

Codex e ChatGPT possuem responsabilidades diferentes

A nova arquitetura também separa claramente os ambientes.

Codex

Responsável por:

• estrutura;

• validação;

• leitura dos arquivos;

• geração das análises;

• produção do resumo em Markdown;

• versionamento;

• atualização controlada do histórico após aprovação.

ChatGPT

Responsável por:

• revisão editorial;

• ajustes finais;

• validação humana assistida;

• geração de DOCX;

• geração de PDF;

• preparação da entrega ao cliente.

Essa divisão permite utilizar cada ambiente naquilo que ele faz melhor.

O relatório executivo passou a ser uma narrativa única

O resumo final não possui quatro capítulos independentes reproduzindo cada plataforma.

Ele integra as fontes em uma única narrativa.

Sua estrutura é:

1. Resumo Geral

2. Pontos Fortes

3. Pontos de Atenção

4. Impacto Geral no Projeto

5. Recomendações Priorizadas

As recomendações são separadas em:

• alta prioridade;

• média prioridade;

• baixa prioridade.

Cada recomendação deve responder:

• o que fazer;

• por que fazer;

• onde atuar;

• qual resultado é esperado;

• como validar no próximo ciclo.

O relatório precisa ser curto o suficiente para leitura executiva e detalhado o suficiente para sustentar decisões.

O que mudou entre a primeira e a segunda geração

A primeira geração provou que era possível automatizar a análise mensal com IA, histórico e revisão humana.

A segunda geração transformou essa experiência em governança.

As principais evoluções foram:

• inclusão de Google Ads como fonte obrigatória;

• separação entre arquitetura, inteligência e conhecimento;

• prompts especializados;

• controlador de execução;

• manifesto mais estruturado;

• política de versionamento;

• proteção dos arquivos locais;

• governança de hipóteses;

• níveis de confiança;

• memória com critérios de promoção;

• política de obsolescência do conhecimento;

• vocabulário oficial;

• regras específicas para temas sensíveis;

• distinção formal entre volume e eficiência;

• estrutura preparada para múltiplos clientes.

O framework não elimina o trabalho consultivo

Automação não significa retirar o consultor do processo.

Significa retirar o consultor das tarefas repetitivas para que ele possa se concentrar no que realmente gera valor:

• validar interpretações;

• entender o contexto;

• priorizar ações;

• identificar riscos;

• discutir decisões com o cliente;

• acompanhar a execução.

O framework organiza a informação.

A consultoria transforma essa informação em decisão.

Próximas etapas

A arquitetura foi desenhada para evoluir por meio de uso real.

As próximas etapas incluem:

• processamento de competências reais;

• validação operacional do manifesto;

• refinamento da memória mensal;

• automação da identificação dos relatórios;

• scripts de preparação da competência;

• comparação histórica automatizada;

• integração direta com APIs;

• alertas de anomalias;

• geração assistida dos arquivos finais;

• expansão do framework para outros projetos.

A partir deste ponto, novas mudanças não devem surgir apenas de desenho teórico.

Elas devem ser orientadas por problemas encontrados durante a operação.

De uma automação para uma plataforma de inteligência

A principal conclusão dessa evolução é que um sistema de relatórios com IA não deve ser tratado como um prompt conectado a arquivos.

Ele precisa funcionar como uma plataforma.

Essa plataforma precisa saber:

• quais dados pode utilizar;

• como interpretar cada métrica;

• quais fontes devem ser correlacionadas;

• quando uma conclusão é confiável;

• quando uma hipótese precisa de validação;

• quando uma recomendação é prioritária;

• o que deve ser lembrado;

• o que deve ser esquecido;

• o que pode ser versionado;

• quando o processo deve parar para revisão humana.

Foi essa mudança de perspectiva que transformou nosso projeto.

A primeira geração automatizou a consolidação.

A segunda geração estruturou a inteligência.

O próximo passo é utilizar esse framework em operação real, acumular histórico aprovado e continuar evoluindo a arquitetura com base em evidências.

Na Ad Rock, inteligência artificial não é utilizada apenas para gerar textos mais rapidamente.

Ela é incorporada à arquitetura dos processos.

O objetivo é construir sistemas mais consistentes, auditáveis, escaláveis e úteis para tomada de decisão.