Numa migração de CRM ou de ERP, ninguém fala das oficinas de mapeamento. É justamente ali que os projetos empacam. Quando se migra um CRM vertical de saúde para uma plataforma generalista, é preciso comparar, campo a campo, dois modelos de dados que não conversam de forma nativa. Algumas centenas de objetos, alguns milhares de campos, regras de negócio invisíveis na documentação.
O método clássico: oficinas que se arrastam com as equipes funcionais, planilhas que envelhecem mal, entregável de mapeamento que nunca fica de fato fechado. Orçamento consumido antes mesmo do primeiro pipeline de integração.
Num projeto recente, comprimimos essa fase de 3 semanas para 4 dias colocando um LLM no lugar certo. Eis o que aprendemos e, sobretudo, os limites em que esbarramos.
O verdadeiro gargalo: o mapeamento, não o ETL
Na maioria das migrações de SaaS para SaaS, a parte técnica (pipelines de extração, transformação e carga) está bem coberta por ferramentas. MuleSoft, Talend, Informatica IDMC, Workato: as ferramentas sabem ler um esquema, aplicar um mapeamento, tratar os retries. Não é aí que os projetos saem do trilho.
O bloqueio está a montante. As equipes funcionais e de TI precisam concordar sobre qual campo vai para onde. Num perímetro típico, isso representa 15 a 30 objetos de negócio a mapear, 300 a 600 campos a aproximar, 50 a 100 casos que pedem uma decisão (campo customizado, transformação, valor padrão) e várias oficinas de 2 a 3 horas, com 5 a 8 pessoas por sessão.
No fim: uma planilha Excel. Às vezes, duas ou três versões em paralelo. E uma equipe de integração que precisa redigitar tudo isso na ferramenta de destino.
O que a IA muda na prática
As definições dos objetos estão disponíveis via API. Describe no Salesforce, Metadata API nos CRMs verticais de saúde, esquemas JSON ou WSDL na maioria dos SaaS corporativos. Esses esquemas são utilizáveis diretamente por um LLM.
O padrão que validamos: um agente que recebe na entrada os dois esquemas (origem e destino), passa os dois por um prompt estruturado em três etapas e produz um JSON de mapeamento tipado, validado por um output parser.
Esquema 1 · Do esquema de API bruto ao mapeamento injetável nas ferramentas de ETL
Do esquema de API bruto ao mapeamento injetável nas ferramentas de ETL.
As três etapas do prompt não são cosméticas. Elas repetem a sequência que um especialista de integração percorre de cabeça.
Etapa 1: match exato por nome. A gente reconcilia os campos que têm exatamente o mesmo nome. É óbvio, mas já cobre 20 a 30% das correspondências em esquemas homogêneos.
Etapa 2: aproximação semântica. É aqui que o LLM se paga. Email__c para PersonEmail. Date_Naissance para Birthdate. Remoção dos sufixos __c, tratamento de camelCase vs snake_case, reconhecimento de sinônimos funcionais. Uma pessoa também faz isso, só que devagar e com lapsos. O LLM faz em poucos segundos, sobre 400 campos.
Etapa 3: proposta de campos customizados. Para os campos sem equivalente, o LLM propõe um nome, um tipo e uma descrição. O especialista tem a última palavra, mas parte de um rascunho, não de uma página em branco.
O entregável muda de natureza
Antes, o entregável era um Excel. Difícil de versionar, impossível de injetar automaticamente numa ferramenta, reformatado a cada passagem de bastão.
Com um LLM por trás de um output parser, o entregável passa a ser um JSON estruturado, conforme um esquema. Para cada campo mapeado:
Esse JSON não é consumido nativamente pelos ETLs do mercado. Nenhum deles aceita um manifesto de mapeamento arbitrário na entrada. Em compensação, ele é utilizável por um gerador de código escrito uma vez e apontado para a ferramenta: geração de scripts DataWeave para o MuleSoft, chamadas à API REST do Informatica IDMC para criar os mapeamentos de forma programática, manipulação dos arquivos de projeto do Talend pelo SDK. O JSON funciona como artefato normalizado que alimenta esses adaptadores. A integração não começa mais de uma folha em branco. Começa de um pré-mapeamento injetado na ferramenta pelo adaptador certo.
Os ganhos observados, e os limites deles
Num perímetro de cerca de 15 objetos de negócio e 400 campos:
- Fase de mapeamento inicial: de 3 semanas para 4 dias
- Taxa de cobertura automática (match exato + semântica): em torno de 70%
- Entregável utilizável já na primeira passagem, onde normalmente se precisava de 2 ou 3 iterações
- Custo marginal de inferência: alguns euros por passagem completa num modelo rápido (Gemini, Qwen)
Esses números vêm de um único projeto. Eles não se generalizam sozinhos. A cobertura cai em esquemas muito customizados, em modelos de dados antigos ou mal documentados, ou quando o vocabulário de negócio é específico da empresa. Num esquema exótico, às vezes se cai para 40% de automação. O valor do padrão continua, mas o tamanho do ganho tem de ser reavaliado caso a caso.
O human-in-the-loop não é negociável
É a parte que as equipes com pressa querem pular. É também a que transforma uma geração de IA num entregável confiável. Sem a etapa humana, três categorias de erro vão para produção.
Esquema 2 · O LLM gera, duas passagens humanas validam
O LLM gera, duas passagens humanas validam. Não há atalho possível.
As regras de negócio invisíveis. Um campo Status__c com 4 valores pode esconder 15 anos de lógica. Workflows, status transitórios, convenções internas. Nenhum LLM adivinha que ACTIVE_PENDING_REVIEW deve ir para dois campos distintos no destino, conforme o contexto de criação. Essas regras saem das oficinas e das conversas, não das APIs.
A conformidade regulatória. Regras de residência de dados, de pseudonimização e de direito ao esquecimento não se deduzem de um esquema. Num setor regulado (saúde, finanças, RH), uma equipe de governança precisa validar cada campo sensível. Isso vale ainda mais para dados de saúde (artigo 9 do RGPD, certificação HDS na França).
As transformações condicionais complexas. Um LLM produz bem a regra "formatação de data ISO para o formato US". Produz mal "se o paciente foi criado antes de 2018, aplicar a lógica de RGPD anterior à reformulação; caso contrário, a lógica atual". Regras temporais, exceções não documentadas, convenções não escritas: isso é trabalho de especialista, não de agente.
A armadilha clássica
Pegar o JSON gerado, fazer o gerador de código engolir e ligar o ETL em seguida, sem etapa de revisão. Ganho de tempo aparente, incidente garantido na primeira entrada em produção. Pré-mapeamento sem validação é um rascunho fantasiado de entregável. A passagem humana não é uma etapa opcional. É o que transforma a geração por IA em ativo do projeto.Como colocar isso em prática
A arquitetura cabe numa semana de desenvolvimento. As peças: ingestão de API (os dois esquemas JSON por um simples endpoint HTTP, portável para n8n, Lambda ou um microsserviço), agente LLM com prompt estruturado e output parser de JSON tipado, escolhendo um modelo rápido pelo custo (Gemini, Qwen; não é preciso a potência de um modelo de fronteira para mapeamento), UI de revisão leve para aceitar, modificar ou rejeitar campo a campo e exportar o JSON consolidado (três dias de desenvolvimento com um framework padrão) e um gerador de código para o ETL: um adaptador por ferramenta de destino, que traduz o JSON validado para o formato utilizável (API REST para o Informatica IDMC, DataWeave para o MuleSoft, SDK para o Talend — desenvolvimento único, reutilizável em todos os projetos seguintes).
Último elemento que não se negocia: a rastreabilidade. Cada decisão de mapeamento fica registrada com data e hora, autor e versão do esquema de origem. Útil para auditoria, indispensável num setor regulado.
O setup completo fica de pé em 1 a 2 semanas. O ROI aparece já na primeira oficina evitada. Numa migração de 15 objetos, o build se paga de primeira, e a ferramenta é reaproveitada em todos os projetos seguintes.
Para ir além
Se você está preparando uma migração de CRM ou de ERP, ou uma integração de SaaS para SaaS, e já vê as oficinas de mapeamento chegando com apreensão, este padrão se aplica ao seu caso. Implantamos isso em empresas de saúde, indústria e serviços desde 2024. O primeiro mapeamento automatizado sai em menos de duas semanas, com a UI de revisão incluída.
