ATA 20/05

Ata de Reunião — Implantação de IA no Comercial

Projeto: C26002-ATVX — Implantação de IA no Comercial
Data: 20/05/2026
Duração: 1h13min35s
Participantes:

• Lucas C. Arruda — Autvix Group
• Gustavo L. Schwartz — Autvix Group

Fonte: Transcrição da reunião “Reunião em [C26002-ATVX] Implantação de IA no Comercial”. :contentReference[oaicite:0]{index=0}

1. Objetivo da reunião

Alinhar o andamento do projeto de IA aplicado ao processo comercial, com foco em:

• processamento e classificação de e-mails;
• uso de LLM e regressão logística;
• tratamento das solicitações vindas da Petronect;
• diferenciação entre oportunidades públicas, convites e dispensas;
• definição do escopo mínimo viável do MVP;
• próximos passos técnicos para implementação.

2. Pontos discutidos

2.1 Benchmark e avaliação dos modelos

Foi discutida a necessidade de comparar diferentes modelos utilizados no processamento das solicitações.

O foco da prova de conceito, neste momento, não é avaliar se a resposta está “bonita” ou bem redigida, mas sim se ela é verídica e correta em relação ao conteúdo analisado.

Foi mencionado que as saídas devem seguir um formato padronizado, preferencialmente em JSON, para facilitar o tratamento posterior via código, regex ou integração com outros componentes do sistema.

Também foi levantada a necessidade de separar os resultados por modelo, criando pastas ou estruturas distintas para permitir comparação entre as execuções.

2.2 Fluxo atual de processamento de e-mails

Foi explicado que o sistema atual possui um endpoint responsável por receber o caminho da pasta do e-mail processado.

O fluxo descrito foi:

1. receber o caminho da pasta do e-mail;
2. localizar o arquivo HTML;
3. extrair o texto do e-mail;
4. aplicar filtros iniciais;
5. verificar se é e-mail interno;
6. verificar se é resposta;
7. classificar se é ou não uma solicitação;
8. aplicar modelos de classificação;
9. gerar confiança consolidada com base nas classificações.

A classificação atual utiliza uma combinação de abordagens, incluindo:

• regressão logística;
• vetorização com TF-IDF;
• análise de remetente;
• análise de cliente;
• análise de tipos de anexos;
• chamada para LLM;
• cálculo de confiança ponderada.

2.3 Uso de LLM e regressão logística

Foi discutido que a regressão logística depende de um dataset treinado especificamente para a tarefa desejada.

O dataset atual classifica se um e-mail é ou não uma solicitação. Para classificar se uma solicitação Petronect é pública ou convite/dispensa, seria necessário outro dataset, pois se trata de uma classificação diferente.

Também foi discutida a possibilidade de criar uma chamada para LLM com prompt específico para essa nova classificação.

No entanto, para o caso específico da Petronect, foi entendido que talvez não seja necessário iniciar com modelo de IA, já que os e-mails possuem padrões textuais que podem ser tratados por regra simples.

3. Petronect — classificação de oportunidades públicas e convites

3.1 Problema identificado

Inicialmente, havia a hipótese de usar a API da Petronect para diferenciar oportunidades públicas de convites ou dispensas.

A lógica proposta era:

• se a API retornasse dados, a oportunidade seria pública;
• se a API retornasse vazio, nulo ou 404, a oportunidade seria tratada como convite ou dispensa.

Durante a reunião, foi identificado que essa lógica não era suficientemente segura, pois houve casos em que uma oportunidade aparentemente pública não retornou corretamente pela API.

Com isso, concluiu-se que a API não deve ser a única fonte de decisão para classificar a oportunidade.

3.2 Decisão sobre o filtro Petronect

Foi decidido que a classificação entre pública e convite/dispensa deve considerar o corpo do e-mail.

A regra inicial definida foi:

• se o corpo do e-mail contiver termos como “licitação pública” ou “oportunidade pública”, classificar como:

  • Petronect - Oportunidade Pública

• se o corpo do e-mail contiver termos como “sua empresa foi convidada”, classificar como:

  • Petronect - Convite
  • ou Petronect - Dispensa, conforme nomenclatura final a ser adotada.

Foi comentado que essa verificação pode ser implementada com uma lógica simples, como busca textual, regex ou consulta no banco, desde que o corpo do e-mail esteja salvo.

3.3 Uso da API da Petronect

A API continuará sendo considerada útil para buscar informações adicionais da oportunidade pública.

Entretanto, ela não será usada isoladamente para definir se a oportunidade é pública ou convite.

Fluxo acordado:

1. identificar se o e-mail é uma solicitação;
2. verificar se é Petronect;
3. analisar o corpo do e-mail;
4. classificar como oportunidade pública, convite ou dispensa;
5. quando for pública e houver retorno da API, buscar dados complementares;
6. quando não houver retorno da API, não assumir automaticamente que não é pública;
7. salvar a classificação para consulta posterior.

4. MVP e limites do escopo

Foi reforçado que o projeto deve seguir com uma abordagem de MVP, priorizando a entrega funcional antes de buscar refinamentos excessivos.

A decisão foi trabalhar com as informações atualmente disponíveis, mesmo que a base da empresa ainda não esteja totalmente estruturada.

Foram citados alguns pontos que podem gerar limitações:

• BU genérica demais;
• ausência de documentação detalhada de famílias Petronect;
• falta de mapeamento completo de quais famílias a empresa atende;
• ausência de portfólio técnico detalhado;
• requisitos de qualidade por família ainda não tratados;
• possibilidade de classificações incorretas por falta de informação de negócio.

A orientação foi: primeiro entregar uma solução funcional e, quando os gargalos aparecerem em produção, tratar as melhorias com base em evidências.

5. Famílias Petronect

Foi discutido que a Petronect trabalha com famílias de fornecimento e que a empresa pode estar cadastrada em diferentes famílias.

Foi levantada a possibilidade de, futuramente, existir uma rotina para verificar ou atualizar automaticamente o cadastro da empresa nas famílias da Petronect.

No entanto, foi definido que esse tema não entrará como prioridade do MVP, pois a empresa ainda não possui documentação interna suficiente indicando:

• quais famílias atende;
• quais requisitos técnicos cumpre;
• quais famílias não fazem sentido para o negócio;
• quais produtos ou serviços estão associados a cada família.

A conclusão foi que esse tipo de refinamento depende de informações do negócio e poderá ser tratado futuramente.

6. BU e qualidade das classificações

Foi identificado que a BU atual pode estar genérica demais.

Exemplo discutido: uma BU que menciona “projetos elétricos” pode levar o modelo a concluir que a empresa atende uma solicitação de painel elétrico, mesmo que esse item não faça parte do escopo real da empresa.

Foi entendido que esse problema não é exclusivamente do software, mas também da qualidade da informação fornecida ao modelo.

A melhoria da BU foi considerada importante, mas não impeditiva para o MVP.

7. Requisitos de qualidade e SGQ

Foi discutido que algumas solicitações podem exigir requisitos específicos de qualidade, associados ao SGQ ou a categorias técnicas.

Foi citado que a empresa pode atender determinado item, mas não atender um requisito de qualidade específico exigido naquela oportunidade.

Apesar disso, ficou decidido que, no MVP, o sistema não fará essa validação detalhada.

A classificação inicial será baseada principalmente em aderência ao escopo da empresa.

Validações mais específicas, como requisitos de qualidade, famílias, tipos de fornecimento ou restrições técnicas, poderão ser adicionadas em fases futuras.

8. Interface, dashboard e acompanhamento

Foi discutida a existência de uma interface para visualização das classificações e acompanhamento dos e-mails.

Foi levantada a comparação com Metabase, mas foi apontado que a necessidade principal não é apenas visualizar gráficos, e sim permitir que o usuário veja os e-mails classificados, filtre por status e acompanhe o processo de triagem.

Também foi mencionado que ferramentas como Plums ou sistemas comerciais podem receber apenas aquilo que já está dentro do escopo, enquanto o sistema de IA precisa lidar também com:

• fora do escopo;
• não solicitação;
• solicitação em análise;
• solicitação Petronect;
• oportunidades públicas;
• convites;
• respostas e e-mails internos.

9. Decisões tomadas

1. A classificação Petronect não dependerá exclusivamente da API.
2. O corpo do e-mail será usado para identificar se a solicitação é pública ou convite.
3. Termos como “licitação pública” e “oportunidade pública” indicarão oportunidade pública.
4. Termos como “sua empresa foi convidada” indicarão convite ou dispensa.
5. A API será usada para buscar dados complementares, mas não como única regra de classificação.
6. O MVP não tratará, neste primeiro momento, regras avançadas de famílias Petronect.
7. O MVP não tratará, neste primeiro momento, requisitos específicos de qualidade/SGQ.
8. O sistema será desenvolvido com base na realidade atual das informações disponíveis.
9. Melhorias de BU, famílias e requisitos técnicos serão tratadas futuramente, conforme surgirem gargalos.
10. A classificação deverá ser salva para consulta posterior em banco, dashboard ou interface de acompanhamento.

10. Encaminhamentos

11. Pendências

• Definir a nomenclatura final entre:

  • Petronect - Convite;
  • Petronect - Dispensa;
  • Petronect - Oportunidade Fechada.

• Validar mais exemplos reais de e-mails Petronect para confirmar os padrões textuais.

• Verificar se o corpo do e-mail está sendo salvo no banco para permitir consultas futuras.

• Definir onde a classificação será exibida:

  • dashboard;
  • caixa de entrada da interface;
  • banco de dados;
  • Metabase;
  • outra ferramenta de acompanhamento.

• Avaliar futuramente a necessidade de:

  • scraping para convites;
  • atualização automática de famílias;
  • documentação técnica por família;
  • validação de requisitos de qualidade;
  • refinamento da BU.

12. Conclusão

A reunião consolidou que o projeto deve seguir com foco em entrega de MVP, evitando aprofundar neste momento em regras complexas de negócio que dependem de documentação ainda inexistente ou incompleta.

Para as solicitações da Petronect, ficou definido que a classificação entre oportunidade pública e convite/dispensa deve ser feita inicialmente por análise do corpo do e-mail, usando padrões textuais identificáveis. A API será mantida como apoio para buscar informações adicionais, mas não como única fonte de decisão.

O objetivo imediato é colocar o fluxo em produção com regras simples, validar o comportamento com dados reais e evoluir o sistema conforme os gargalos aparecerem.