Pular para o conteúdo
Pedro Pólido

São Paulo, Brasil · Disponível para projetos

IA que trabalhaonde o processojá acontece

Trabalho na fronteira entre IA aplicada e integração de sistemas. Construí a Tria, que já triou mais de 10 mil candidatos dentro do WhatsApp, e a Percam, que acompanha o técnico de campo da saída de casa até a RAT verificada. Meu trabalho começa onde a API do cliente já existe: integro, automatizo e entrego sistema que roda em produção, não protótipo de demonstração.

Ford · Tech Mahindra · Tria · Percam

Status · 2026
Produtos autorais
2
Candidatos triados
10.000+
Cases de cliente
2
Base
São Paulo, BR

Stack núcleo

TypeScript · Python · n8n · Docker · PostgreSQL

  • 10 mil+candidatos triados pela Tria
  • 175.554VINs reais no treino do Faro AI
  • 5 fontes + IAagregadas com proveniência por campo
  • 54rotas REST tipadas com Zod
Role ↓
[02]Sobre5 campos

Integração é onde os projetos de IA travam. É onde eu entro.

Identificação

Pedro HenriquePólido Martins

Engenheiro de Software & IA Aplicada

Fig. 01 — Pedro Pólido · São Paulo · 2026

Sou Pedro Henrique Pólido Martins, de São Paulo, estudante de Engenharia de Software na FIAP. Os dois produtos que construí — Tria e Percam — nasceram de processos que já existiam na operação do cliente e que precisavam de uma camada de inteligência em cima, não de mais um software para a equipe aprender do zero.

Minha especialidade é fazer sistemas conversarem: WhatsApp, Cervello, Sankhya, Google API, Meta e APIs governamentais. A maior parte dos projetos de IA não morre no modelo, morre na integração — no dado que não sai do ERP, no CRM que só atualiza no fim do dia, no canal em que o usuário final realmente está. É exatamente aí que eu trabalho.

Uso LLM com critério, não como bala de prata. No Faro AI, o padrão que defendi vale para qualquer produto sério: modelo determinístico como baseline de custo zero, LLM acionado só na zona cinza, mesclagem ponderada quando os dois concordam e flag explícita de revisão humana quando discordam — com as duas predições guardadas lado a lado para auditoria.

O que eu entrego não é demo: é sistema com fallback, log, verificação de integridade e uma resposta pronta para a pergunta “e quando o provedor de IA cair?”.

Base
São Paulo, Brasil
Foco
IA aplicada · Integração de sistemas · Automação
Formação
Engenharia de Software — FIAP
Stack núcleo
TypeScript · Python · n8n · Docker · PostgreSQL
Modelo de trabalho
Projetos sob medida e consultoria
[03]Produtos autorais2 registros

Dois produtos meus, rodando no canal onde a operação já vive.

Produto_01 / TriaRecrutamento & Seleção

Tria

IA conversacional de recrutamento que mora dentro do WhatsApp.

A Tria faz a triagem de candidatos onde o candidato já está: no WhatsApp. Sem link para portal, sem formulário de quarenta campos, sem app para instalar — a conversa é a triagem. Já passaram mais de 10 mil candidatos por ela, e o recrutador recebe o resultado organizado em vez de uma caixa de entrada cheia de currículo solto.

  • Triagem 100% conversacional no WhatsApp: zero fricção de cadastro para o candidato.
  • Mais de 10 mil candidatos já triados em operação real, não em piloto.
  • Perguntas conduzidas por LLM a partir dos critérios reais da vaga, definidos pelo time de RH.
  • Disponível 24/7: o candidato responde no horário dele e o recrutador recebe já filtrado.
  • Integrada aos sistemas que o RH já usa, para o resultado cair direto no fluxo existente.
10.000+candidatos triados
WhatsAppMeta APILLM / Prompt Engineeringn8nDockerIntegrações sob medida
Produto_02 / PercamAtendimento em campo

Percam

Follow-up de campo com IA: da saída de casa até a RAT verificada.

Atendimento em campo tem um buraco clássico de informação: entre o técnico sair de casa e o chamado ser fechado no sistema, ninguém sabe direito onde as coisas estão. A Percam cobre esse trajeto inteiro com IA de follow-up — acompanha o deslocamento, verifica a RAT (Relatório de Atendimento Técnico) e atualiza o CRM em tempo real, sem depender de o técnico lembrar de lançar nada no fim do dia.

  • Rastreio do trajeto completo: saída de casa, deslocamento, chegada, atendimento e conclusão.
  • Verificação da RAT antes do fechamento — o chamado não encerra com relatório incompleto.
  • CRM atualizado em tempo real, não no lançamento retroativo do fim do expediente.
  • Follow-up ativo conduzido por IA, no canal que o técnico já usa no dia a dia.
  • Visibilidade para o gestor sem microgerenciamento: o status chega sozinho.
Ponta a pontada saída de casa à RAT verificada
WhatsAppGoogle APICRM em tempo realSankhya / CervelloLLMn8nDocker
[04]Cases de cliente2 registros

Trabalho entregue para cliente, com o número que dá para comprovar.

As métricas abaixo foram verificadas no código dos repositórios, não nos READMEs. Cada destaque aponta o arquivo que o sustenta.

Problema

A Ford trouxe dois desafios. Na Inteligência Competitiva, o time comercial precisa comparar veículos concorrentes num formato padronizado, mas os dados estão espalhados em tabela FIPE, sites de fabricantes com WAF que bloqueia scraping, catálogos em PDF e bases americanas — nenhum confiável sozinho. Na Retenção (VIN Share), a concessionária perde o cliente para oficinas independentes após a garantia e não sabe, no ato da venda, quem vai sumir: o histórico bruto tem centenas de milhares de linhas de ordens de serviço, sem rótulo de perfil e sem nada priorizado para o consultor agir.

Abordagem

Para o Desafio 1, um agregador que consulta as fontes em cascata (FIPE, NHTSA vPIC, HTML do site oficial extraído com IA, e-book PDF da fabricante e catálogo 411) e só aciona o LLM para preencher lacunas remanescentes, gravando a origem de cada campo individual. Para o Desafio 2, um ETL em pandas que agrega o XLSX bruto por VIN e monta uma base só com features pré-compra (sem data leakage) para treinar XGBoost; em produção, o gateway roda o modelo como baseline determinístico e chama o LLM como crítico apenas na zona cinza. O ranking de leads roda como função SQL dentro do Postgres, contornando o teto de 1.000 linhas do PostgREST.

Meu papel

Fui responsável pela camada de dados do projeto: o ETL em pandas que reduziu cerca de 600 mil linhas de ordens de serviço a 175.554 VINs sem data leakage, a ingestão do catálogo do desafio de inteligência competitiva e a decisão arquitetural — registrada no DECISIONS.md do repositório — de adotar o Supabase como fonte única de verdade, com Postgres, RLS multi-tenant, 18 migrations versionadas e as funções SQL de ranking que empurram o cálculo pesado para dentro do banco. Também respondi pela operação e rotação das credenciais da plataforma de dados. Projeto de equipe: cinco integrantes.

Arquitetura

Pipeline de dados do Faro AI5 fontes → Agregador → LLM (lacunas) → Postgres + RLS → Leads ranqueados5 fontesAgregadorLLM (lacunas)Postgres + RLSLeads ranqueados

Destaques técnicos

  • Agregação de 5 fontes com proveniência campo a campo

    O agregador encadeia FIPE, NHTSA vPIC, HTML do site oficial, e-book PDF da fabricante e catálogo 411, e só aciona o LLM quando faltam specs. Cada atributo é etiquetado com a origem exata, a prioridade de merge é explícita e a confiança geral deriva de quantas fontes reais responderam. A interface diferencia dado oficial de valor estimado por IA.

    apps/api/src/lib/data-sources/aggregator.ts
  • Ensemble ML + LLM com zona cinza e revisão humana

    O XGBoost é sempre o baseline determinístico e de custo zero; o LLM só entra quando a confiança do ML cai abaixo de 0,6. Em concordância, as probabilidades são mescladas por média ponderada; em discordância, vence a maior confiança, o resultado é penalizado em 20% e a predição é marcada para revisão humana, com as duas predições persistidas para auditoria.

    apps/api/src/modules/retention/hybrid-classifier.ts
  • Pseudonimização HMAC e payload assinado no túnel API → ML

    Nenhuma PII atravessa a fronteira até o serviço Python: o identificador da concessionária vira um HMAC-SHA256 truncado em 16 caracteres e o corpo inteiro é assinado em header próprio. A verificação usa timingSafeEqual no Node e compare_digest no Python, evitando ataque de timing nas duas pontas. Se o serviço cai, há fallback heurístico determinístico.

    apps/api/src/modules/retention/ml-client.ts
  • RLS multi-tenant como segunda camada de autorização

    Todas as tabelas sobem com RLS habilitado sob a regra de negar por padrão, com policies expressas em funções security definer. O analista enxerga apenas a própria concessionária, o gestor a rede. No lado da aplicação, o plugin Fastify revalida o JWT contra o endpoint de usuário em vez de confiar no payload.

    supabase/migrations/20260514_002_rls_policies.sql
  • Cálculo pesado empurrado para dentro do Postgres

    Em vez de paginar centenas de milhares de linhas pelo PostgREST, funções SQL fazem o trabalho no banco: o risco composto por lead é calculado com bônus por revisão atrasada, garantia vencida e baixa fidelidade ao dealer, devolvendo o array de sinais que justifica cada posição. Sobre esse resumo, a API calcula z-score e separa anomalias de benchmarks.

    supabase/migrations/20260514_018_leads_ranking_fn.sql
  • ETL em pandas e classificador sem data leakage

    O pipeline lê o XLSX bruto, converte para Parquet com cache por mtime e agrega por VIN com features comportamentais. A base de treino mantém só o que existe no ato da venda — modelo, ano, dealer, sazonalidade —, e o XGBoost roda dentro de um Pipeline sklearn com split estratificado e métricas serializadas junto ao modelo.

    scripts/etl-d2-real.py
  • Extração multimodal escalonada por custo

    A rota mais barata é tentada primeiro: extração local de PDF, com heurística exigindo volume de texto e palavras-chave técnicas para decidir se vale a rota textual. O JSON passa por validação antes de ser aceito — se vier lixo, cai para visão e depois para outro provedor. Modelos caros são deliberadamente evitados por padrão, com o custo de cada rota documentado.

    apps/api/src/lib/ai-vision.ts
175.554VINs reais Ford BR no treino
54rotas REST tipadas com Zod
262atributos no schema canônico
18migrations versionadas com RLS
~600 mil → 175 millinhas reduzidas a 1 por veículo no ETL
3 provedores / 10 modelosLLMs com failover em cascata
TypeScript 5.7Node.js 20Fastify 5ZodOpenAPI / SwaggerNext.js 15React 19Tailwind CSSReact NativeExpo RouterSupabasePostgreSQLPython 3.11FastAPIXGBoostscikit-learnpandasParquetOpenAIAnthropicGeminiGitHub Actionsgitleaks

Problema

Equipes de pista precisam de duas informações com latências muito diferentes: as condições ambientais que definem a estratégia de pneus, que toleram segundos de atraso e precisam ser historicizadas num dashboard remoto, e a passagem do carro pelo ponto de cronometragem, que precisa de resposta imediata e local. Centralizar as duas coisas na nuvem introduz latência e um ponto único de falha justamente no evento mais sensível a tempo — e rede instável em ambiente de pista não pode silenciar o alerta de volta.

Abordagem

Um nó ESP32 concentra três periféricos em GPIOs dedicados e roda um laço de 2 segundos que garante a sessão MQTT viva, amostra os sensores e publica. A telemetria ambiental sobe em tópicos separados por grandeza, permitindo que o dashboard assine só o que precisa; já a regra de negócio da volta é executada localmente no microcontrolador, então o alerta dispara mesmo com o broker inacessível. A robustez de rede vem de client ID randomizado por sessão, laço de reconexão com diagnóstico do código de retorno e guarda contra leitura inválida antes de publicar.

Meu papel

Titular do repositório e do copyright registrado na licença MIT do projeto. Integrante da equipe de cinco alunos da sprint. O repositório tem commit único, então a divisão interna de tarefas entre os integrantes não está documentada.

Arquitetura

Pipeline de telemetria da pistaDHT22 · PIR → ESP32 → Regra local → MQTT · 3 tópicos → DashboardDHT22 · PIRESP32Regra localMQTT · 3 tópicosDashboard

Destaques técnicos

  • Regra de negócio decidida no dispositivo

    A detecção de volta não faz round-trip à nuvem: o sensor PIR aciona o buzzer localmente e o estado é publicado em paralelo apenas para registro. O alerta crítico em tempo continua funcionando com o broker fora do ar — que é exatamente o argumento de existir do edge computing, e não só um sensor conectado.

    codigo-wokwi
  • Telemetria MQTT com tópicos segregados por grandeza

    Em vez de um payload JSON monolítico, o firmware publica em três tópicos independentes. Isso deixa o consumidor assinar só a grandeza que lhe interessa — um painel de estratégia pode ouvir apenas umidade; o cronômetro, apenas o PIR — e é o padrão pub/sub correto para fan-out de telemetria.

    codigo-wokwi
  • Client ID MQTT randomizado por sessão

    A cada conexão o dispositivo monta um identificador novo. Detalhe que importa em broker público compartilhado: no MQTT, dois clientes com o mesmo identificador derrubam a sessão um do outro em loop infinito — a randomização elimina essa classe de falha.

    codigo-wokwi
  • Guarda de integridade antes de publicar

    O DHT22 retorna valor inválido em leitura falha. O código valida temperatura e umidade antes de qualquer publicação, então a série temporal no broker nunca recebe amostra corrompida. Validação na origem, no edge, em vez de empurrar limpeza de dados para o back-end.

    codigo-wokwi
3tópicos MQTT segregados por grandeza
2.000 mscadência de amostragem e publicação
262 Hz / 1 sassinatura sonora do alerta de volta
5.000 msintervalo de retry na reconexão MQTT
C++ / ArduinoESP32MQTTPubSubClientSensor DHT22Sensor PIRBuzzer piezoelétricoBroker HiveMQWokwiLicença MIT
[05]Serviços6 categorias

O que eu faço quando o processo já existe e precisa funcionar melhor.

S/01 · Especialidade

Integração de sistemas

WhatsApp, Cervello, Sankhya, Google API, Meta e APIs governamentais. Conecto o que já existe na sua operação, tratando os casos chatos: rate limit, falha de provedor, retry, reconciliação e o que fazer quando a outra ponta simplesmente não responde.

S/02

IA conversacional e agentes LLM

Assistentes que atendem no canal onde o usuário já está, com prompt engineering aplicado a regra de negócio real. Multi-provedor com fallback em cascata, para que a queda de uma API não vire indisponibilidade do produto.

S/03

Desenvolvimento de sistemas sob medida

Software construído para a necessidade específica do cliente, não configuração forçada de uma ferramenta genérica. Do backend tipado à interface, com o processo do cliente ditando o desenho — e não o contrário.

S/04

Automação de processos com n8n

Fluxos que eliminam o trabalho repetitivo entre sistemas: captura, tratamento, decisão e escrita de volta na origem. Automação versionada e observável, com tratamento explícito de erro em vez de silêncio.

S/05

Consultoria de automação de processos

Mapeamento do processo antes de escrever qualquer linha: onde está o gargalo real, o que vale automatizar, o que vale só simplificar e o que não deveria existir. Diagnóstico honesto, inclusive quando a resposta é que IA não é a solução ali.

S/06

Engenharia de dados e ML aplicado

ETL em pandas, features sem data leakage, classificadores XGBoost com métricas honestas em holdout e ensemble ML + LLM com flag de revisão humana. No Faro AI isso significou transformar cerca de 600 mil linhas brutas em 175.554 VINs prontos para treino.

Formato: projeto ou consultoriaModelo: remotoBase: São Paulo, BR

[06]Competências52 itens

Ferramentas

Nenhuma barra de porcentagem: a lista é literal. O que importa é como as peças se combinam — modelo determinístico primeiro, LLM onde ele agrega, e integração que aguenta a outra ponta cair.

Dia a dia

Orquestração
n8n
Contêineres
Docker
Banco
PostgreSQL / Supabase
Canal
WhatsApp / Meta API
Modelos
OpenAI · Anthropic · Gemini
CI
GitHub Actions

IA & Machine Learning

10

LLM / Prompt EngineeringEnsemble ML + LLMOpenAIAnthropicGeminiXGBoostscikit-learnpandasExtração multimodalXAI / explicabilidade

Integrações & Automação

09

WhatsAppMetaCervelloSankhyaGoogle APIAPIs governamentaisn8nWebhooksCRM em tempo real

Backend & APIs

10

TypeScriptNode.jsFastifyExpressZodOpenAPI / SwaggerPythonFastAPIC# / .NETJava / Spring Boot

Dados & Infraestrutura

08

PostgreSQLSupabaseRLS multi-tenantMigrations versionadasETL / ParquetDockerGitHub ActionsMonorepo pnpm

Segurança & Privacidade

07

Pseudonimização HMAC-SHA256Assinatura de payloadComparação em tempo constanteJWTRate limitinggitleaks no CIBoas práticas de LGPD

Front-end, Mobile & Edge

08

Next.jsReactTailwind CSSReact NativeExpoESP32C++ / ArduinoMQTT

[07]Outros projetos6 repositórios

Repositórios públicos que mostram o resto do alcance.

Todos públicos em github.com/P0lid0 ↗

[08]Contato4 canais

Tem um processo que trava toda semana?

Me conte onde ele quebra.

Me conte qual é o fluxo, quais sistemas ele atravessa e onde ele quebra. Eu respondo com um caminho concreto: o que dá para automatizar agora, o que precisa de integração antes e o que não vale a pena resolver com IA.

São Paulo, Brasil · Disponível para projetos