# ATA - 06/05

# ATA DE REUNIÃO

**Projeto:** C26002-ATVX – Implantação de IA no Comercial

<table class="code-line" data-line="4" dir="auto" id="bkmrk-campo-informa%C3%A7%C3%A3o-dat"><thead class="code-line" data-line="4" dir="auto"><tr class="code-line" data-line="4" dir="auto"><th>Campo</th><th>Informação</th></tr></thead><tbody class="code-line" data-line="6" dir="auto"><tr class="code-line" data-line="6" dir="auto"><td>Data</td><td>06 de maio de 2026</td></tr><tr class="code-line" data-line="7" dir="auto"><td>Horário</td><td>17h01</td></tr><tr class="code-line" data-line="8" dir="auto"><td>Duração</td><td>2h08min28s</td></tr><tr class="code-line" data-line="9" dir="auto"><td>Formato</td><td>Reunião remota com compartilhamento de tela</td></tr><tr class="code-line" data-line="10" dir="auto"><td>Participantes identificados</td><td>Lucas C. Arruda – Autvix Group; Gustavo L. Schwartz – Autvix Group</td></tr><tr class="code-line" data-line="11" dir="auto"><td>Fonte</td><td>Transcrição da gravação da reunião</td></tr></tbody></table>

## 1. Objetivo da reunião

Revisar o estado atual do sistema de implantação de IA no Comercial, incluindo arquitetura, requisitos funcionais e não funcionais, modelo de dados, fluxo de ingestão de e-mails, observabilidade, dashboards e evolução dos filtros de classificação. A reunião também teve como objetivo definir ajustes técnicos, prioridades de implementação e próximos prazos do projeto.

## 2. Pauta tratada

- Apresentação do fluxo atual de captura, sincronização, validação e armazenamento de e-mails.
- Revisão dos requisitos funcionais e não funcionais já documentados ou implementados.
- Discussão sobre a complexidade atual envolvendo OneDrive, Fuse Poller, Watch/Inotify, Power Automate, MySQL, Metabase e Grafana.
- Análise de inconsistências na base, especialmente duplicidade de IDs de mensagens e definição do `folder_path` como referência única.
- Revisão do modelo de dados, com foco na tabela principal de e-mails, contatos, clientes e classificação.
- Avaliação dos testes de classificação de IA, métricas de acurácia e matriz de confusão.
- Definição dos próximos passos, responsáveis e prazos para migração, testes e entregáveis.

## 3. Principais discussões

### 3.1 Arquitetura e fluxo atual

Foi revisado que o fluxo atual envolve captura de e-mails, geração de pastas, sincronização via OneDrive, detecção por mecanismo baseado em Inotify/Fuse Poller, validação dos dados e inserção em banco MySQL. Também foram citados Metabase e Grafana para visualização e observabilidade. Foi destacado que o fluxo atual funciona, mas possui uma cadeia de serviços extensa e complexa.

### 3.2 Complexidade técnica e necessidade de simplificação

Lucas destacou que o projeto apresenta profundidade técnica em pontos como logs, migrations e observabilidade, mas ainda possui pendências em elementos essenciais do entregável, como estruturação definitiva da base e do filtro principal. Foi defendida a priorização do esqueleto funcional e entregável ao cliente antes de novas camadas de refinamento técnico.

### 3.3 Migração para Microsoft Graph API / Power Automate

A equipe convergiu que a migração do fluxo atual para uma abordagem baseada em Microsoft Graph API, possivelmente via Power Automate, deve reduzir a complexidade lógica e operacional. A substituição reduziria dependências de OneDrive, Fuse Poller e Watch/Inotify, além de facilitar rastreabilidade e confiabilidade do processamento.

### 3.4 Revisão do banco de dados

A tabela de e-mails foi tratada como principal por valor agregado, pois concentra as informações recebidas e serve como base para auditoria, dashboards e relacionamento com classificações. Foi reforçado que o banco não deve ser o mecanismo principal de processamento do modelo, mas sim um repositório histórico, de auditoria e análise futura.

### 3.5 Campos da tabela de e-mails

Foi discutida a manutenção de campos como ID, `contato_id`, `classificacao_id`, destinatário, `subject`, data de recebimento, data de processamento, `folder_path`, quantidade de anexos, nomes dos anexos e ID da mensagem. Foi sugerida a remoção de `body_html` e `body_text`, pois os arquivos correspondentes já ficam salvos na pasta, evitando duplicidade e ambiguidade.

### 3.6 Contatos, clientes e domínios

Foi diferenciada a entidade contato da entidade cliente: contato representa quem envia e-mails, enquanto cliente representa a base de clientes cadastrados. Ficou indicado que os domínios de remetentes devem ser relacionados posteriormente a clientes, com apoio de pessoas da área comercial, já que a equipe técnica não possui domínio completo para essa vinculação.

### 3.7 Classificação e filtros de IA

Lucas apresentou testes com regressão logística, banco vetorial, LLM e combinação dos modelos. Foi mencionada acurácia combinada em torno de 91% em amostra de teste e acurácia de 96% na regressão logística sobre 1.097 dados. Também foi reforçada a necessidade de testar com dados não usados no treinamento para validar a real capacidade de generalização.

### 3.8 Métricas, dashboards e observabilidade

A dashboard é considerada requisito do sistema para visualização dos e-mails e indicadores. Foram discutidas métricas como quantidade de anexos, nomes/extensões de arquivos, status de processamento e saúde dos serviços. A observabilidade atual usa Grafana e registros em tabela de status dos serviços.

### 3.9 Integrações externas e limitações

Foi comentada a limitação relacionada a APIs de portais externos, especialmente Petrobras/Petronet. A equipe reconheceu que parte desses problemas depende de terceiros, mas que será necessário acompanhar e cobrar resolução para viabilizar etapas futuras.

## 4. Decisões e alinhamentos

1. Priorizar a entrega funcional do projeto antes de aprofundar novas camadas de refinamento técnico.
2. Migrar o fluxo atual para Microsoft Graph API/Power Automate, substituindo dependências excessivas de OneDrive, Fuse Poller e Watch/Inotify sempre que possível.
3. Tratar a tabela de e-mails como a tabela principal para histórico, auditoria, dashboards e relacionamento com classificações.
4. Manter o `folder_path` como referência para localização dos arquivos do e-mail e para consultas futuras, especialmente após classificação.
5. Revisar a base de dados para eliminar inconsistências, especialmente duplicidade de `message_id`, reconstruindo a base se necessário a partir dos dados salvos.
6. Remover ou deixar de utilizar campos redundantes como `body_html` e `body_text` enquanto não houver necessidade clara de uso no banco.
7. Distinguir contato de cliente no modelo de dados, mantendo contato como remetente/domínio e cliente como entidade de cadastro comercial.
8. Delegar a vinculação de domínios a clientes para pessoas com conhecimento comercial, como Juliana e/ou Vidal, por meio de planilha de validação.
9. Focar inicialmente na classificação “solicitação” versus “não solicitação”, antes de aprofundar o filtro de dentro/fora do escopo.
10. Reexecutar testes da pipeline de classificação com dados não utilizados no treinamento, para medir acurácia de forma mais confiável.

## 5. Encaminhamentos e responsáveis

<table class="code-line" data-line="80" dir="auto" id="bkmrk-%23-a%C3%A7%C3%A3o-respons%C3%A1vel-p"><thead class="code-line" data-line="80" dir="auto"><tr class="code-line" data-line="80" dir="auto"><th>\#</th><th>Ação</th><th>Responsável</th><th>Prazo</th></tr></thead><tbody class="code-line" data-line="82" dir="auto"><tr class="code-line" data-line="82" dir="auto"><td>1</td><td>Implementar a migração do fluxo atual para Graph API/Power Automate, reduzindo dependências de OneDrive/Fuse/Watch.</td><td>Gustavo</td><td>Até 07/05/2026, 17h</td></tr><tr class="code-line" data-line="83" dir="auto"><td>2</td><td>Recarregar ou reconstruir a base de e-mails, validando duplicidades e consistência do `message_id` e do `folder_path`.</td><td>Gustavo</td><td>Após migração para Graph API</td></tr><tr class="code-line" data-line="84" dir="auto"><td>3</td><td>Revisar o modelo de dados da tabela de e-mails, removendo campos redundantes e mantendo os campos essenciais para auditoria e dashboard.</td><td>Lucas e Gustavo</td><td>Curto prazo</td></tr><tr class="code-line" data-line="85" dir="auto"><td>4</td><td>Exportar lista de domínios/contatos e solicitar validação de associação com clientes à área comercial.</td><td>Gustavo, com apoio de Juliana/Vidal</td><td>A definir</td></tr><tr class="code-line" data-line="86" dir="auto"><td>5</td><td>Revisar prompt/system prompt e repetir testes da pipeline de classificação.</td><td>Lucas</td><td>Antes da próxima validação técnica</td></tr><tr class="code-line" data-line="87" dir="auto"><td>6</td><td>Separar dados não utilizados no treinamento para nova rodada de testes de acurácia.</td><td>Lucas, com apoio operacional a definir</td><td>Curto prazo</td></tr><tr class="code-line" data-line="88" dir="auto"><td>7</td><td>Iniciar desenvolvimento de novo filtro após estabilização da ingestão e validação inicial da classificação.</td><td>Lucas</td><td>Após testes e base ajustada</td></tr><tr class="code-line" data-line="89" dir="auto"><td>8</td><td>Buscar bios/dados da Davis/Multimix ou focar inicialmente em uma única empresa para simplificar o recorte do teste.</td><td>Lucas/Romeu</td><td>Até 11/05/2026, se possível</td></tr><tr class="code-line" data-line="90" dir="auto"><td>9</td><td>Acompanhar pendências com APIs externas, especialmente Petronet/Petrobras.</td><td>Lucas</td><td>Contínuo</td></tr><tr class="code-line" data-line="91" dir="auto"><td>10</td><td>Preparar dashboard robusta para apresentação, com base nos dados disponíveis.</td><td>Gustavo</td><td>Até 11/05/2026</td></tr></tbody></table>

## 6. Prazos combinados

<table class="code-line" data-line="95" dir="auto" id="bkmrk-data-entrega%2Fmarco-0"><thead class="code-line" data-line="95" dir="auto"><tr class="code-line" data-line="95" dir="auto"><th>Data</th><th>Entrega/Marco</th></tr></thead><tbody class="code-line" data-line="97" dir="auto"><tr class="code-line" data-line="97" dir="auto"><td>07/05/2026, até 17h</td><td>Conclusão estimada da migração inicial para Graph API/Power Automate e ajustes de base.</td></tr><tr class="code-line" data-line="98" dir="auto"><td>11/05/2026, até 17h</td><td>Meta de ter pré-classificador em conjunto com a base ajustada; possibilidade de dashboard robusta.</td></tr><tr class="code-line" data-line="99" dir="auto"><td>29/05/2026</td><td>Meta indicativa para ter algo rodando no Comercial. O prazo foi reconhecido como desafiador, especialmente para a parte de IA.</td></tr></tbody></table>

## 7. Pontos em aberto

- Confirmar o desenho final da arquitetura após a migração para Graph API/Power Automate.
- Validar se o ID da mensagem será único em todos os cenários e como será tratado quando houver múltiplos destinatários.
- Definir com precisão quais campos permanecerão nas tabelas de e-mails, contatos, clientes e classificação.
- Confirmar o mecanismo final de entrega dos resultados classificados ao cliente: CRM, plataforma futura, dashboard ou outro canal.
- Avaliar a viabilidade de integração com portais externos e contornar limitações de APIs de terceiros.
- Definir quem fará a rotulagem/validação de dados não treinados para os próximos testes.

## 8. Encerramento

A reunião foi encerrada após a definição dos próximos passos técnicos, com foco na simplificação da arquitetura, revisão do modelo de dados, melhoria da confiabilidade da ingestão de e-mails e continuidade dos testes de classificação. A próxima etapa prática é a migração para Graph API/Power Automate, seguida da validação da base e avanço do pré-classificador.

---

Ata elaborada a partir da transcrição da reunião.