IA generativa em sistemas empresariais: arquitetura RAG, padrões de copilot e detecção de anomalias com LLM

A IA generativa saiu do ChatGPT e entrou nos sistemas que rodam as empresas

Em 2024, IA generativa era ChatGPT na aba do navegador. Em 2025, virou copilot dentro do IDE. Em 2026, está dentro do ERP, do CRM, do WMS — onde os dados vivem e as decisões acontecem.

Mas existe uma diferença enorme entre "colocar um chat de IA no sistema" e "integrar IA generativa de forma que resolva problemas reais do negócio". A maioria das implementações que vemos no mercado brasileiro cai na primeira categoria: um chatbot genérico com acesso a uma base de conhecimento mal indexada, que responde perguntas vagas com respostas vagas.

As implementações que geram valor real seguem padrões de arquitetura específicos: RAG bem construído, copilot patterns que se integram ao fluxo de trabalho do usuário, detecção de anomalias que antecipa problemas, e auto-reporting que elimina horas de trabalho manual.

Esse post é o deep-dive técnico nesses padrões — como funcionam, quando aplicar cada um, e quais são as armadilhas que separam POC de produção.

O fundamento: por que LLMs sozinhos não servem para sistemas empresariais

Um LLM (Large Language Model) como Claude, GPT-4 ou Llama foi treinado em dados públicos da internet. Ele sabe o que é um balanço patrimonial, mas não sabe o balanço patrimonial da sua empresa. Ele sabe o que é ICMS, mas não sabe a alíquota que se aplica ao seu produto no estado do destino.

Para um LLM ser útil dentro de um sistema empresarial, ele precisa de contexto específico do negócio. Existem 3 formas de fornecer esse contexto:

1. Fine-tuning (ajuste fino)

Treinar o modelo com dados da empresa. Problema: caro, lento, precisa re-treinar quando os dados mudam, e o modelo pode "esquecer" conhecimento geral.

Quando usar: quando o padrão de linguagem do domínio é muito específico (ex: jargão jurídico de um nicho, linguagem técnica de uma indústria). Não é o caso para a maioria dos sistemas empresariais.

2. In-context learning (prompt engineering)

Colocar informações relevantes diretamente no prompt. Funciona para contextos pequenos, mas não escala — o prompt tem limite de tokens, e colocar todo o banco de dados no prompt é impossível.

Quando usar: informações estáticas e pequenas (regras de negócio, políticas, personas).

3. RAG (Retrieval-Augmented Generation)

Buscar informações relevantes no banco de dados/documentos da empresa e injetar no prompt antes de gerar a resposta. É o padrão dominante para sistemas empresariais.

Quando usar: sempre que o LLM precisa acessar dados que mudam (pedidos, clientes, estoque, financeiro, documentos).

Arquitetura RAG para sistemas empresariais: além do básico

O RAG básico (chunk → embedding → vector store → retrieval → prompt → LLM) funciona para perguntas sobre documentos. Mas em sistemas empresariais, os dados são estruturados (tabelas SQL), não apenas documentos de texto. Isso muda a arquitetura.

RAG sobre dados estruturados (SQL-RAG)

O padrão mais poderoso para sistemas empresariais: o LLM gera consultas SQL a partir de perguntas em linguagem natural.

Usuário: "Qual foi o faturamento do cliente ABC nos últimos 3 meses?"
                    ↓
┌─────────────────────────────────┐
│   Schema Retriever              │
│   (busca tabelas/colunas        │
│    relevantes no catálogo)      │
└──────────────┬──────────────────┘
               ↓
┌─────────────────────────────────┐
│   SQL Generator (LLM)           │
│   Prompt:                       │
│   - Schema das tabelas          │
│   - Exemplos de queries         │
│   - Regras de segurança         │
│   - Pergunta do usuário         │
│                                 │
│   Output:                       │
│   SELECT SUM(valor_total)       │
│   FROM pedidos                  │
│   WHERE cliente_id = 'ABC'      │
│   AND data >= DATEADD(month,    │
│       -3, GETDATE())           │
└──────────────┬──────────────────┘
               ↓
┌─────────────────────────────────┐
│   Query Validator               │
│   - Verifica segurança          │
│   - Verifica permissões do user │
│   - Limita resultado (LIMIT)    │
│   - Bloqueia DELETE/UPDATE/DROP │
└──────────────┬──────────────────┘
               ↓
┌─────────────────────────────────┐
│   Query Executor (READ-ONLY)    │
│   Executa contra réplica de     │
│   leitura do banco              │
└──────────────┬──────────────────┘
               ↓
┌─────────────────────────────────┐
│   Response Generator (LLM)      │
│   "O faturamento do cliente     │
│    ABC nos últimos 3 meses foi  │
│    R$ 847.320,00, distribuído:  │
│    Abril: R$ 312k               │
│    Maio: R$ 289k                │
│    Junho: R$ 246k"              │
└─────────────────────────────────┘

Cuidados críticos do SQL-RAG

Segurança: o LLM nunca deve executar queries diretamente. Toda query gerada passa por validador que:

• Rejeita qualquer operação que não seja SELECT
• Aplica filtro de permissão do usuário (row-level security)
• Adiciona LIMIT para evitar queries que retornam milhões de linhas
• Executa em réplica de leitura, nunca no banco de produção

Precisão: LLMs cometem erros de SQL. Para aumentar a precisão:

• Fornecer exemplos de queries corretas no prompt (few-shot learning)
• Incluir descrições de colunas ambíguas ("valor_total é o valor com impostos, valor_liquido é sem impostos")
• Validar resultado com query de conferência quando possível
• Mostrar a query gerada ao usuário para transparência

RAG híbrido: documentos + dados estruturados

Na prática, um sistema empresarial tem dados em SQL (pedidos, clientes, financeiro) E documentos (contratos, manuais, editais, e-mails). O RAG híbrido combina os dois:

Pergunta do usuário
        ↓
┌───────────────────┐
│   Router (LLM)    │
│   Classifica a    │
│   pergunta:       │
│   - SQL? → SQL-RAG│
│   - Doc? → Doc-RAG│
│   - Ambos? → Merge│
└─────┬─────────────┘
      ↓
┌──────────┐  ┌──────────────┐
│ SQL-RAG  │  │ Document-RAG │
│          │  │ (pgvector/   │
│          │  │  Pinecone)   │
└────┬─────┘  └──────┬───────┘
     └────────┬──────┘
              ↓
     ┌────────────────┐
     │ Response Merge  │
     │ (LLM combina   │
     │  resultados)    │
     └────────────────┘

A Bradata utiliza essa abordagem híbrida em suas integrações de IA, permitindo que usuários façam perguntas que cruzam dados transacionais com documentos anexados ao sistema.

Padrões de Copilot para sistemas empresariais

O conceito de copilot (assistente inteligente integrado ao fluxo de trabalho) vai muito além de "chat no canto da tela". Os padrões que realmente agregam valor:

Padrão 1 — Auto-complete contextual

O sistema sugere o próximo valor antes do usuário digitar, baseado no contexto.

Exemplo em cadastro de produto:

• Usuário digita a descrição do produto: "Parafuso sextavado M10 x 50mm aço carbono"
• Sistema sugere automaticamente:
  • NCM: 7318.15.00 (parafusos e pernos)
  • Unidade: PC (peça)
  • CFOP padrão: 5.102 (venda dentro do estado)
  • CST ICMS: 00 (tributado integralmente)

Implementação: LLM recebe a descrição + catálogo de produtos similares + tabela NCM e retorna sugestões. Cache agressivo para produtos com descrições parecidas.

Padrão 2 — Validação inteligente com explicação

Em vez de apenas mostrar "erro no campo X", o copilot explica o porquê e sugere correção.

Exemplo em NF-e:

⚠️ CFOP 5.102 incompatível com CST 60
Explicação: CST 60 indica que o ICMS já foi recolhido 
por Substituição Tributária. Nesse caso, o CFOP correto 
para venda dentro do estado é 5.405 (venda de mercadoria 
adquirida em operação com ST).
[Aplicar correção] [Ignorar]

Implementação: regras fiscais codificadas detectam o erro, LLM gera a explicação em linguagem natural. Não depende do LLM para detectar o erro — usa IA apenas para explicar.

Padrão 3 — Resumo executivo automático

O sistema gera resumos de dados complexos sem que o usuário precise montar relatórios.

Exemplo em dashboard financeiro:

📊 Resumo da semana (27/mai - 02/jun):
- Faturamento: R$ 1,2M (+8% vs semana anterior)
- 3 clientes representam 47% do faturamento
- Inadimplência subiu para 4,3% (era 3,1% — analisar 
  cliente Delta Comércio que tem R$ 180k vencidos há 45 dias)
- Estoque de produto X abaixo do ponto de pedido 
  (12 unidades, mínimo é 50)
- 7 NF-es rejeitadas (5 por erro de NCM — verificar 
  cadastro de novos produtos)

Implementação: queries SQL pré-definidas extraem os dados, LLM sintetiza em texto narrativo com destaque para anomalias. Pode ser enviado por e-mail ou exibido no login.

Padrão 4 — Assistente de preenchimento de formulários complexos

Para formulários com muitos campos interdependentes (cadastro fiscal, proposta comercial, licitação), o copilot guia o usuário.

Exemplo em cadastro de empresa (cliente ou fornecedor):

1. Usuário informa CNPJ
2. Sistema consulta Receita Federal (API pública) e preenche: razão social, endereço, CNAE
3. Copilot analisa CNAE e sugere: regime tributário provável, se é contribuinte de ICMS, se é optante do Simples
4. Copilot valida Inscrição Estadual no cadastro SINTEGRA
5. Campos preenchidos automaticamente com alta confiança, campos duvidosos marcados para revisão humana

Padrão 5 — Geração de documentos a partir de dados

LLM gera documentos complexos (contratos, propostas, relatórios) a partir de dados estruturados + templates.

Exemplo: gerar relatório de due diligence a partir de dados financeiros do ERP:

• Input: dados de faturamento, inadimplência, composição de custos, passivos trabalhistas
• Output: relatório de 10 páginas com análise de risco, gráficos textuais e recomendações
• Template: estrutura do documento é fixa, conteúdo é gerado pelo LLM

Detecção de anomalias com LLM

LLMs são surpreendentemente bons em detectar padrões anômalos quando recebem contexto adequado. Os casos de uso em sistemas empresariais:

Anomalias financeiras

Input para o LLM: últimos 12 meses de lançamentos contábeis de uma conta específica.

Conta: Despesas com Frete (conta 4.1.03.002)
Meses anteriores: R$ 22k, R$ 24k, R$ 21k, R$ 23k, 
R$ 25k, R$ 22k, R$ 24k, R$ 23k, R$ 21k, R$ 24k
Mês atual: R$ 67k

Análise: Despesa com frete 2,9x acima da média dos 
últimos 10 meses. Possíveis causas a investigar:
1. Aumento de volume de entregas (verificar pedidos)
2. Troca de transportadora com custo superior
3. Lançamento duplicado ou em conta errada
4. Reajuste de frete não negociado

Implementação: job batch diário ou semanal que roda análise estatística simples (média, desvio padrão) para detectar outliers, e usa LLM para gerar a narrativa explicativa com hipóteses. O LLM não faz a detecção estatística — ele contextualiza.

Anomalias em pedidos

Alerta: Pedido #45.892 — anomalia detectada
- Cliente: Empresa XYZ (cliente há 3 anos)
- Valor do pedido: R$ 340.000
- Média de pedidos anteriores: R$ 28.000
- Pedido é 12x maior que a média
- Produto: 5.000 unidades de Item A (maior pedido 
  anterior: 400 unidades)
- Condição de pagamento: 90 dias (cliente normalmente 
  paga à vista)

Recomendação: Validar pedido com representante 
comercial antes de faturar. Verificar limite de crédito.

Anomalias em RH

• Funcionário com 15 horas extras por semana durante 8 semanas seguidas (risco trabalhista)
• Departamento com turnover de 40% nos últimos 6 meses (problema de gestão)
• Picos de atestados médicos em datas específicas (padrão suspeito)

O LLM analisa os dados no contexto histórico e gera alertas com linguagem clara para gestores não técnicos.

Auto-reporting: relatórios que se escrevem sozinhos

A geração automática de relatórios é um dos casos de uso com ROI mais claro. Gestores gastam horas montando relatórios semanais e mensais que seguem o mesmo formato — mudam apenas os dados.

Arquitetura de auto-reporting

┌─────────────────────────┐
│   Scheduler (cron)       │
│   Semanal / Mensal       │
└──────────┬──────────────┘
           ↓
┌─────────────────────────┐
│   Data Collector         │
│   Queries pré-definidas  │
│   contra o banco         │
└──────────┬──────────────┘
           ↓
┌─────────────────────────┐
│   Analyzer (LLM)         │
│   Compara com período    │
│   anterior               │
│   Detecta tendências     │
│   Identifica anomalias   │
└──────────┬──────────────┘
           ↓
┌─────────────────────────┐
│   Report Generator       │
│   Template + dados +     │
│   narrativa do LLM       │
│   Output: PDF, HTML, Slack│
└──────────┬──────────────┘
           ↓
┌─────────────────────────┐
│   Distributor            │
│   E-mail para diretoria  │
│   Slack para gestores    │
│   Dashboard para todos   │
└─────────────────────────┘

Exemplo de relatório auto-gerado

RELATÓRIO SEMANAL DE VENDAS — Semana 22/2026

RESUMO EXECUTIVO
Faturamento da semana: R$ 2,34M (↑12% vs semana 21)
Pedidos emitidos: 847 (↑7%)
Ticket médio: R$ 2.763 (↑5%)
NF-es emitidas: 891 | Rejeitadas: 12 (taxa: 1,3%)

DESTAQUES POSITIVOS
• Região Sudeste superou meta semanal em 18%
• Produto "Linha Premium" cresceu 34% em volume
• Taxa de inadimplência caiu de 3,8% para 3,2%

PONTOS DE ATENÇÃO
• Região Nordeste ficou 22% abaixo da meta
• 3 clientes concentram 38% do faturamento (risco)
• Estoque do SKU #4455 em nível crítico (2 dias)
• Rejeições de NF-e concentradas em NCM 8471 
  (verificar cadastro de produtos de informática)

COMPARATIVO MENSAL (Junho parcial vs Maio)
[tabela com dados comparativos]

Esse relatório que levaria 2-3 horas para montar manualmente é gerado em 30 segundos. O gestor revisa, ajusta se necessário, e distribui.

Custos e otimização: como não quebrar o orçamento

O custo de LLM em produção escala com o uso. As técnicas de otimização:

Caching semântico

Perguntas parecidas recebem a mesma resposta do cache em vez de ir para o LLM.

Pergunta 1: "Qual o faturamento de maio?"
→ Gera resposta, cacheia com embedding da pergunta

Pergunta 2: "Quanto faturamos em maio?"
→ Embedding similar ao da pergunta 1
→ Retorna resposta do cache (sem custo de LLM)

Economia: 30-50% de redução de chamadas ao LLM em cenários com perguntas repetitivas.

Model routing

Usar modelos diferentes para complexidades diferentes:

• Perguntas simples (saldo, consulta de dados) → modelo pequeno e barato (Claude Haiku, GPT-4o-mini)
• Análise complexa (relatório, anomalia) → modelo grande (Claude Opus, GPT-4o)
• Classificação e routing → modelo mínimo (fine-tuned pequeno ou regex)

Economia: 40-60% quando a maioria das interações são consultas simples.

Batching

Agrupar múltiplas perguntas ou tarefas em uma única chamada ao LLM:

Em vez de:
  Chamada 1: "Classifique este produto: Parafuso M10"
  Chamada 2: "Classifique este produto: Porca M8"
  Chamada 3: "Classifique este produto: Arruela lisa 3/8"

Fazer:
  Chamada única: "Classifique os seguintes produtos:
  1. Parafuso M10
  2. Porca M8
  3. Arruela lisa 3/8
  Retorne NCM e unidade para cada um."

Economia: reduz overhead de tokens do sistema prompt (que é o mesmo para todas as chamadas).

Governança de IA em sistemas empresariais

Colocar IA em sistemas que lidam com dados financeiros, fiscais e pessoais exige governança:

Rastreabilidade

Toda decisão influenciada por IA deve ser rastreável:

• Qual modelo foi usado
• Qual prompt foi enviado
• Qual resposta foi gerada
• Se o usuário aceitou, editou ou rejeitou a sugestão

Explicabilidade

O sistema deve ser capaz de explicar por que a IA sugeriu X:

• "Sugeri NCM 7318.15.00 porque produtos similares no seu catálogo (Parafuso M8 sextavado, Parafuso M12 allen) usam esse NCM"

Limites de autonomia

Definir claramente o que a IA pode fazer automaticamente vs. o que precisa de aprovação humana:

Ação	Nível de autonomia
Sugerir NCM para produto novo	Automático com revisão
Classificar ticket de suporte	Automático
Gerar relatório semanal	Automático
Aprovar crédito para cliente	Somente sugestão, decisão humana
Corrigir NF-e rejeitada	Sugestão + confirmação do usuário
Alterar preço de produto	Bloqueado para IA

LGPD e dados pessoais

Se o sistema de IA processa dados pessoais (nomes, CPFs, dados de RH):

• Dados não podem ser enviados para APIs de LLM externas sem base legal
• Anonimização ou pseudonimização antes de enviar ao LLM
• Ou uso de modelo on-premise (Llama, Mistral) para dados sensíveis

Implementação prática: roadmap de 6 meses

Para empresas que querem integrar IA generativa em seus sistemas, o roadmap que funciona:

Mês 1-2: Caso de uso piloto

Escolher um caso de uso de alto valor e baixo risco:

• Chatbot de consulta de dados (faturamento, estoque, clientes)
• Auto-complete de cadastro de produtos
• Resumo executivo semanal

Implementar com RAG básico, medir satisfação e precisão.

Mês 3-4: Refinamento e segundo caso de uso

Otimizar o piloto (caching, model routing, melhorar retrieval). Implementar segundo caso de uso, geralmente mais complexo:

• Detecção de anomalias financeiras
• Assistente de preenchimento fiscal
• Geração de propostas comerciais

Mês 5-6: Escala e governança

Implementar framework de governança (logs, rastreabilidade, limites). Escalar para mais módulos do sistema. Definir métricas de sucesso (tempo economizado, erros evitados, satisfação do usuário).

A Bradata segue esse roadmap em suas integrações de IA, começando sempre pelo caso de uso que gera valor demonstrável mais rápido, para justificar o investimento nos casos seguintes.

O futuro próximo: agentes autônomos em sistemas empresariais

A próxima fronteira é a transição de copilot (assistente passivo que responde quando perguntado) para agente (sistema que age proativamente).

Exemplos de agentes em sistemas empresariais:

• Agente que monitora estoque e gera pedido de compra automaticamente quando atinge ponto de pedido
• Agente que detecta NF-e rejeitada, identifica o erro, corrige e retransmite sem intervenção humana
• Agente que analisa inadimplência e envia comunicação personalizada para cada cliente devedor
• Agente que monitora contratos e alerta 60 dias antes do vencimento com sugestões de renegociação

A diferença entre agente e automação tradicional (que já existe): o agente lida com variabilidade. A automação tradicional segue regras fixas. O agente interpreta contexto, toma decisões em cenários não previstos, e aprende com feedback.

Estamos no início dessa transição. As empresas que construírem a infraestrutura de IA agora (RAG, copilot, governança) estarão prontas para agentes quando a tecnologia amadurecer. As que esperarem vão enfrentar uma curva de aprendizado muito mais íngreme.

Conclusão: IA generativa em sistemas empresariais é arquitetura, não feature

Integrar IA generativa em sistemas empresariais não é adicionar um botão de chat. É uma decisão de arquitetura que afeta segurança, custos, governança e experiência do usuário. Os padrões que funcionam — RAG híbrido, copilot contextual, detecção de anomalias, auto-reporting — seguem princípios de engenharia sólidos: separação de responsabilidades, segurança por design, otimização de custos e rastreabilidade.

A tecnologia está madura o suficiente para gerar valor real em produção. O que diferencia implementações que funcionam das que viram custo sem retorno é a profundidade da arquitetura e o foco em casos de uso que resolvem problemas reais do negócio, não em demonstrações impressionantes que não sobrevivem à produção.