Incorporamos IA em processos que já funcionam
Dados, modelos, integração com seus sistemas e suporte após o lançamento.
A IA aqui não é um produto separado, mas uma camada de processamento sobre dados que a empresa já acumula: pedidos, chamados, documentos, movimentações de mercadoria, eventos de equipamentos. Abaixo estão as frentes de adoção, e cada uma é descrita por um ciclo: quais dados são usados, o que o modelo faz com eles, qual decisão ou ação decorre disso e o que muda no trabalho da empresa.
Adotar IA — significa embutir um modelo em um processo que já roda, e não lançar um sistema separado ao lado. O modelo lê os dados da empresa, encontra um padrão neles e produz uma decisão; a ação sobre essa decisão é executada pelo sistema em que o processo vive — CRM, ERP, o programa de armazém, o caixa, o portal, o mensageiro.
Por isso um projeto começa não pela escolha de um modelo, mas por quatro respostas: quais dados existem e em que estado estão; qual decisão precisa ser tomada; quem executa essa decisão e com o quê; e qual número vai mostrar que melhorou. Sem qualquer uma das quatro, um modelo acrescenta mais uma fonte de dados pela qual ninguém responde.
Onde a IA não é necessária. Se uma regra pode ser escrita em uma linha — estoque abaixo de cinco unidades, avise compras — ela é escrita como regra: mais barato, previsível e verificável linha a linha. A IA cabe onde há dezenas de sinais, eles mudam com o tempo e uma pessoa até agora decidia no olho: classificar um chamado, estimar a demanda, notar uma operação atípica, extrair campos de um documento em formato livre.
| Tarefa | O que resolve |
|---|---|
| Avisar compras sobre estoque baixo | regra |
| Atribuir um e-mail recebido a um tema e a um departamento | modelo |
| Aplicar um desconto conforme as condições de um contrato | regra |
| Estimar a demanda por um item para daqui a um mês | modelo |
| Verificar se os campos obrigatórios estão preenchidos | regra |
| Encontrar uma operação atípica entre as comuns | modelo |
A linha passa por um critério: a condição pode ser escrita por inteiro. Onde pode, uma regra funciona mais rápido, custa menos e explica a própria decisão. Um modelo é necessário onde a condição é descrita por exemplos, e não por uma linha de texto. Em um sistema em funcionamento os dois não competem, mas ficam lado a lado: o modelo leva uma entrada não estruturada a uma estrutura, e daí em diante quem decide são as regras.

Um piloto é construído sobre dados históricos e comparado com a linha de base sobre esses mesmos dados. Se o modelo não superar a forma atual de trabalhar em um período passado, ele não vai para produção.
Toda frente abaixo é descrita por esse ciclo. Ele também é uma forma de testar qualquer proposta de adoção de IA: se ela não nomeia os quatro elos, é uma demonstração de capacidades, e não um processo em funcionamento.
O que entra: pedidos e pagamentos, chamados e correspondência, documentos e digitalizações, movimentações de mercadoria, eventos de equipamentos, registros do sistema contábil. A fonte, a profundidade do histórico e a frequência de atualização são todas declaradas.
O que o modelo faz: atribui um objeto a uma classe, extrai campos, estima um valor, encontra um desvio da norma, ordena opções, formula uma resposta a partir dos documentos que encontrou. Sempre com um número de confiança.
O que acontece com o resultado: o chamado entra na fila de um executor, um status muda no CRM, uma tarefa cai no armazém, um documento é lançado, uma resposta é enviada ao cliente, o caso passa a uma pessoa.
O que é medido: tempo da operação, parcela de decisões tomadas sem uma pessoa, número de erros e retrabalhos, perdas por atrasos e baixas, carga do turno. A comparação é com a linha de base anterior à adoção.
A confiança da classificação foi de 0,94 contra um limiar de 0,80. Abaixo do limiar o chamado teria ido para a fila geral com um tema sugerido, em vez de direto para o departamento de qualidade: um caso limítrofe é tratado por uma pessoa, não pelo modelo.
Dados em uma empresa ficam em lugares diferentes e em estados diferentes: parte na base do sistema contábil, parte no e-mail e em mensageiros, parte em arquivos, parte chegando dos equipamentos. Enquanto a coleta for feita à mão, qualquer análise descreve não o negócio, mas aquilo que alguém conseguiu exportar.
Processamento por IA: do fluxo são extraídas entidades — contraparte, produto, documento, evento; os registros sobre um mesmo objeto são ligados entre si mesmo quando os nomes e as grafias não batem. Casar nomes, endereços e dados cadastrais é trabalho para um modelo, e não para comparação de texto.
O que se conecta:
Ação: o que foi coletado entra em um buffer de dados brutos em que nada é sobrescrito e só então se espalha para bases analíticas, modelos e relatórios. O registro original sempre pode ser levantado e conferido.

Os dados para analítica e modelos aparecem sem exportações manuais e sem uma versão da planilha em cada departamento. A coleta manual deixa de ser trabalho diário e vira exceção, e as divergências entre relatórios são resolvidas pelo registro de carga, e não pela memória dos funcionários.
Dados coletados não estão prontos para uso: o mesmo item é chamado de três formas, as unidades de medida estão misturadas, metade dos registros não tem um atributo obrigatório e parte das linhas são duplicatas de uma mesma operação. Um modelo treinado em um conjunto assim vai reproduzir a bagunça, em vez de encontrar um padrão.
Processamento por IA cobre aqui três tarefas: levar os registros a uma forma única, preencher atributos onde não existem e distribuir os objetos em categorias que não existiam nos dados de origem.
Ação: as correções seguras são aplicadas automaticamente e gravadas no registro com o valor original; as limítrofes vão ao dono do cadastro para confirmação, em uma lista única, e não em e-mails avulsos.
Qualidade de dados não é uma arrumação única antes de um projeto, mas um processo contínuo: os cadastros crescem todo dia, os fornecedores mudam os formatos das listas de preços, e os gerentes criam fichas do zero em vez de procurar a existente. Por isso as regras e os modelos de limpeza vivem no sistema ao lado dos dados e são aplicados a cada carga.
Toda correção tem um autor — uma regra ou um modelo —, um horário e um valor antigo e um novo. Isso não é burocracia: sem o histórico é impossível descobrir por que o relatório do mês passado mostra hoje números diferentes.
Os cadastros param de se ramificar, os relatórios por grupo de produtos e por rubrica de despesa passam a bater entre si, e preparar dados deixa de consumir a maior parte do cronograma de todo projeto de analítica.
| Verificação | Linhas | Resultado |
|---|---|---|
| Casadas com o catálogo | 4 812 | aplicado |
| Unidades de medida normalizadas | 1 106 | aplicado |
| Categoria preenchida a partir da descrição | 438 | aplicado |
| Fichas parecidas, exigem decisão | 96 | aguardando revisão |
| Inconsistências no documento | 14 | devolver ao fornecedor |
Uma tela do sistema: os números são ilustrativos. Vão para revisão apenas os casos abaixo do limiar de confiança — 96 linhas de 6.466; o restante foi aplicado automaticamente, com o valor anterior gravado no registro.
Um relatório comum responde à pergunta que lhe foi feita: receita por mês, vendas por filial, estoque por armazém. As perguntas são feitas por uma pessoa, então você vê exatamente aquilo que alguém pensou em olhar.
Processamento por IA inverte aqui o sentido: o modelo revisa sozinho os recortes e traz aqueles em que um indicador se comporta de forma diferente do esperado. Não «desenhe um gráfico para mim», mas «há três lugares em que algo incomum está acontecendo, e é com isto que se correlaciona».
O que a analítica inteligente faz:
Ação: um achado não fica em um painel — vira uma tarefa com destinatário e prazo: apurar o ponto com a queda, contatar o cliente do grupo de risco, verificar a categoria com devoluções em alta.

Um modelo mostra uma correlação, não uma causa. Um aumento de devoluções em uma categoria pode se explicar por um lote defeituoso, por uma troca de fornecedor, por um erro na descrição do produto ou por um novo canal de venda com outro público — escolher a explicação e tomar a decisão continua com uma pessoa.
Por isso todo achado na interface vem com três coisas: sobre quais dados foi construído, qual é o tamanho do desvio e quais recortes o modelo verificou. Uma conclusão que não pode ser aberta até as linhas de origem não é executada.
A analítica deixa de ser um relatório mensal lido depois do fechamento do período. Um desvio é encontrado no mesmo dia, apurado com a pista quente e custa menos do que quando é notado em uma visão trimestral.
Uma anomalia não é qualquer valor raro, mas um desvio da norma do próprio objeto. Para um ponto de venda, vinte comprovantes por hora é um dia comum; para outro, é motivo de verificação. A norma é calculada a partir do histórico de cada objeto e de um grupo comparável, e não de uma média geral.
Dados: o histórico do indicador para o objeto. Processamento: o modelo constrói um corredor esperado considerando dia da semana, estação e promoções. Ação: sair do corredor cria uma tarefa de apuração. Resultado: uma queda de vendas ou uma falha contábil fica visível no dia em que acontece.
Dados: pagamentos, descontos, devoluções, cancelamentos, edições manuais de documentos. Processamento: avalia-se uma combinação de características — valor, horário, funcionário, frequência. Ação: a operação vai para a fila de controle. Resultado: abusos e enganos são tratados antes do fechamento do período.
Dados: telemetria de dispositivos e terminais. Processamento: procura-se uma mudança no caráter dos eventos que antecede uma falha. Ação: o dispositivo entra na rota de serviço. Resultado: parte das falhas é tratada antes da parada, e não depois de uma reclamação.
Dados: lançamentos, estoque, inventários, transferências. Processamento: fluxos que deveriam bater são confrontados entre si. Ação: uma divergência é registrada com um responsável. Resultado: as faltas são levadas a um lugar específico, e não a um valor único no fim do trimestre.
Dados: o histórico de pedidos, chamados e pagamentos. Processamento: o modelo nota uma quebra no ritmo habitual de compra. Ação: o cliente cai em uma lista para o gerente. Resultado: a saída de um cliente fica visível antes de ele parar de comprar de vez.
Dados: marcas de tempo das etapas de um pedido, de um chamado, de um reparo. Processamento: identificam-se as etapas com duração crescente e as características delas. Ação: a etapa é levada à revisão com números. Resultado: os prazos encurtam onde o tempo está de fato sendo perdido.
| Objeto | O que está errado | Esperado | Físico | Estado |
|---|---|---|---|---|
| Ponto n.º 14 | Receita abaixo do corredor pelo terceiro dia | 98–126 mil | 61 mil | apuração |
| Armazém Sul | Parcela de ajustes manuais de estoque | até 1,5% | 6,2% | apuração |
| Terminal T-207 | Falhas crescentes no módulo de pagamento | 0–2 por dia | 17 | na rota |
| Categoria produtos de limpeza | Devoluções acima da norma da categoria | até 2,1% | 5,8% | aguardando |
Uma tela do sistema: os números são ilustrativos. Cada linha se abre até as operações de origem — um desvio que não pode ser levado aos dados primários nunca entra na fila.
Planejar pelo mês passado erra de forma previsível: não sabe nada sobre a estação, nada sobre a promoção e nada sobre o item ter ficado sem estoque por duas semanas, motivo pelo qual não houve vendas — e não porque não houvesse demanda.
Dados: o histórico de vendas por item e por ponto, os períodos em que o item ficou sem estoque, preços e promoções, o calendário — fins de semana, feriados, início do ano letivo —, o clima onde ele afeta a demanda e os dados de entregas e prazos.
Processamento por IA: o modelo estima a demanda futura para cada par item-ponto e mostra a dispersão à parte: não um número único, mas uma faixa com probabilidade. Para planejar estoque importa mais o limite superior; para planejar receita, o meio.
O que é previsto:
Ação: uma previsão não fica em uma nota — entra no pedido de compra, no plano de reposição dos pontos, na escala de turnos e nos limites de crédito dos clientes. Resultado: menos vendas perdidas por prateleira vazia e menos dinheiro parado em estoque excedente.

Um modelo não é testado nos dados com que aprendeu: o histórico é dividido no tempo, o treino roda no trecho anterior e a verificação no posterior. Isso reproduz a situação real, em que o futuro é desconhecido.
A precisão é medida continuamente, e não uma vez no lançamento: cada linha de previsão é comparada com o realizado quando o período fecha. Um erro crescente é sinal de que o comportamento da demanda mudou e o modelo precisa ser retreinado.
Uma tela do sistema: os números são ilustrativos. Os grupos com erro alto não são escondidos, mas mostrados à parte: para eles o pedido é calculado por uma pessoa, trabalhando com a faixa, e não com um número único.
Rotina são operações que se repetem dezenas de vezes por dia, exigem atenção e não exigem qualificação: copiar dados de um e-mail para uma ficha, atribuir um pagamento a uma rubrica de despesa, designar um executor, conferir se um documento está completo, definir um status.
Processamento por IA é necessária onde a entrada não é formalizada: o e-mail está escrito em palavras, o documento chegou no formato de outra pessoa, a solicitação é redigida de um jeito por cada cliente. O modelo leva essa entrada a uma estrutura, e daí em diante o processo passa a regras comuns — previsíveis e verificáveis.
Operações que passam a ser automáticas:
Ação e resultado: a operação é executada pelo sistema e gravada no registro com autor, horário e valor original. O funcionário passa da digitação de dados ao tratamento de exceções — os casos em que o modelo não tem certeza ou em que o custo de um erro é alto.

Uma ação automática é permitida onde ela pode ser desfeita ou onde um engano é barato: definir um status, designar um executor, criar um rascunho. Operações irreversíveis — movimentar dinheiro, lançar um documento, expedir mercadoria — ficam com uma pessoa ou exigem confirmação.
O limiar de confiança é definido separadamente para cada operação e muda conforme a estatística se acumula. As empresas costumam começar com um limiar alto e um modo de sugestão: o modelo propõe, uma pessoa confirma — e essas confirmações mostram onde se pode confiar nele.
Dados: notas de entrega, faturas, certificados, contratos, especificações, ordens de pagamento, requerimentos, fichas técnicas de equipamentos, e-mails com anexos. Os formatos variam: pdf, foto de celular, digitalização, arquivo de exportação, original em papel.
Processamento por IA: reconhecimento de texto, identificação do tipo de documento, extração de campos e da parte tabular, casamento dos itens com o catálogo e vínculo do documento a um pedido, a um contrato ou a uma contraparte. Para cada campo são devolvidos um valor e um número de confiança.
O que é extraído:
Ação: o documento é conferido contra o pedido e a fatura, as divergências são listadas, e o documento ou é lançado, ou é enviado para revisão a um funcionário específico. Resultado: digitar documentos deixa de ser um trabalho em si, e as divergências são encontradas antes do pagamento, e não no fechamento do mês.
O reconhecimento nunca dá cem por cento de precisão em nenhum conjunto de documentos — e não deveria dar. A questão é outra: o sistema mostra em quais campos confia e quais pede para confirmar. O operador confere alguns campos sinalizados, em vez de digitar o documento inteiro.
Qualidade ruim da origem não é desculpa para um erro silencioso: foto tremida, página cortada, segunda página de uma especificação faltando — tudo isso é sinalizado de forma explícita e devolvido a quem enviou, com o motivo declarado.
A velocidade de processamento deixa de depender do volume do fluxo recebido, e a contabilidade e as compras veem o estado dos documentos em uma lista, e não nas caixas de e-mail de cada funcionário.
Uma tela do sistema: os números são ilustrativos. O documento só é proposto para lançamento depois que as duas sinalizações forem resolvidas — um item novo de catálogo e uma falta exigem, os dois, confirmação humana.
Dados: e-mails, solicitações do site, mensagens em mensageiros, transcrições de ligações, correspondência do chat de suporte, avaliações e notas. Tudo isso é texto em formato livre que até agora uma pessoa precisava ler e triar.
Processamento por IA: o chamado é atribuído a um tema e a um subtema, determinam-se urgência e sentimento, do texto são extraídos o número do pedido, o nome do produto, o endereço e outras entidades, e o chamado é ligado ao histórico do cliente. Chamados repetidos sobre o mesmo assunto são unidos em um caso.
Ação: a solicitação entra na fila do grupo pertinente com os campos já preenchidos, o prazo de resposta é calculado pela urgência, um chamado repetido sobe de prioridade e o cliente recebe uma confirmação com número e prazo previsto.
Resultado: os chamados param de ficar em uma caixa comum até de manhã, e o gerente vê não «muitas reclamações», mas uma estrutura: em quais temas o fluxo cresce, onde o tempo de resposta sobe e quais produtos geram chamados repetidos.
Um chamado isolado fala sobre um caso; o fluxo inteiro fala sobre o produto e o processo. A classificação por tema em um período mostra o que exatamente gera dúvidas: uma instrução confusa, um erro na descrição de um produto, uma falha em uma etapa específica da finalização do pedido, um atraso em uma transportadora.
Por isso os temas não são inventados: primeiro os chamados são agrupados por sentido automaticamente, depois os grupos resultantes são corrigidos à mão e fixados como cadastro. A partir daí ele vive ao lado do produto, e os grupos novos são sugeridos pelo sistema.
| Tema | Parcela | Variação | Primeira resposta |
|---|---|---|---|
| Status e prazos de entrega | 31% | −4% | 6 min |
| Pagamento e estornos | 22% | +9% | 18 min |
| Disponibilidade e características de produtos | 19% | −1% | 4 min |
| Problemas com a área do cliente | 15% | +6% | 27 min |
| Reclamações de qualidade | 13% | 0% | 41 min |
Uma tela do sistema: os números são ilustrativos. Os dois temas em alta — pagamento e área do cliente — não vão para um relatório, mas para o backlog do time de produto, com exemplos de chamados anexados.
Uma recomendação é útil onde a escolha é ampla e a atenção é curta: um catálogo de dezenas de milhares de itens, o sortimento de um ponto, um conjunto de serviços, uma lista curta para um gerente antes de uma ligação. Os dados por trás disso são histórico de pedidos, visualizações, conteúdo do carrinho, devoluções e estoque; o resultado precisa sempre considerar a disponibilidade, senão o sistema recomenda o que não existe.
Processamento: do histórico de pedidos são identificadas combinações estáveis de itens. Ação: a seleção aparece na ficha do produto e no carrinho. Resultado: o número de linhas por comprovante cresce sem pressionar o comprador.
Processamento: o modelo estima a probabilidade de interesse por um item a partir do histórico do cliente e de clientes parecidos. Ação: a oferta vai para a área dele, para um disparo ou para um gerente. Resultado: a resposta é maior do que a de um disparo para todos, e a frequência de contato é menor.
Processamento: a consulta é interpretada por sentido, e não por coincidência de letras: sinônimos, erros de digitação e características são considerados. Ação: os resultados são reordenados. Resultado: menos consultas sem resultado e menos pessoas abandonando o catálogo.
Processamento: comparam-se as vendas de pontos semelhantes e o entorno deles. Ação: propõe-se retirar um item do sortimento ou acrescentá-lo. Resultado: a prateleira é ocupada pelo que de fato vende ali.
Processamento: antes do contato são reunidos o histórico do cliente, as perguntas em aberto e os itens adequados. Ação: a lista curta aparece na ficha do CRM. Resultado: preparar-se para uma ligação leva um minuto, e não dez.
Processamento: estima-se a data prevista de recompra de um material de consumo. Ação: nessa data sai um lembrete. Resultado: menos pedidos recorrentes perdidos e menos contatos sem propósito.
A personalização é limitada por regras explícitas: o que não pode ser recomendado, quais dados não são usados, com que frequência um cliente pode ser contatado e como ele desliga a seleção. Os limites são definidos no sistema, e não deixados como um entendimento verbal.
A visão computacional se justifica em uma classe estreita de tarefas: a cena se repete, o objeto é distinguível e o resultado vira diretamente um evento contábil. Onde essas três condições não são atendidas, uma câmera dá um arquivo de vídeo e alarmes falsos, e não automação.
Onde funciona:
Ação: um evento reconhecido vai não para um arquivo, mas para os registros — para um comprovante, uma tarefa, um termo de recebimento, um registro de infrações. Resultado: some o registro manual daquilo que a câmera já enxerga.

Tarefas em que a cena é diferente a cada vez, a iluminação é arbitrária e o custo de um erro é alto não são cobertas por câmeras. Reconhecimento de emoções, avaliação da diligência de um funcionário, identificação de pessoas em uma multidão comum — isso é pouco confiável, restrito por lei, ou as duas coisas.
Onde importa a precisão, e não a imagem, outros sensores funcionam de forma mais barata e mais confiável: peso, leitor de código de barras, etiqueta, fechadura com registro. Uma câmera se soma a eles, e não os substitui.
Um bot de IA difere de um chatbot de script em um ponto: ele não conduz o usuário por uma árvore de botões, mas entende a pergunta e executa uma ação em um sistema. O valor aqui não está na conversa, mas em a quais dados e operações o bot está conectado — o catálogo, os pedidos, os chamados, o CRM, a base de conhecimento. Um bot sem acesso aos sistemas só sabe parafrasear o manual.

Dados: o catálogo, os preços, o estoque, as condições de entrega e pagamento, os status dos pedidos. Processamento: a pergunta é interpretada por sentido e a resposta é montada com dados atuais, e não com um texto pronto. Ação: escolher um item, calcular a entrega, registrar ou alterar um pedido. Resultado: as perguntas padrão são atendidas 24 horas por dia, enquanto os gerentes cuidam das complexas.
Dados: a base de soluções, o histórico de chamados, a configuração do cliente, os registros do sistema. Processamento: o sintoma é confrontado com casos conhecidos. Ação: instrução passo a passo, verificação de status, criação de um chamado com os dados já reunidos. Resultado: a primeira linha fecha casos repetidos e o engenheiro recebe um chamado com o diagnóstico feito.
Dados: regulamentos, ordens de serviço, instruções, cadastros e relatórios disponíveis ao funcionário conforme as permissões dele. Processamento: busca por sentido e resposta com referência ao item do documento. Ação: abrir uma solicitação ao RH ou a compras, pedir uma certidão, buscar uma aprovação. Resultado: perguntas a colegas e em grupos de chat são substituídas por uma resposta com fonte.
Dados: o texto do chamado, os anexos, o histórico do cliente. Processamento: determinação do tipo de chamado, extração de campos, verificação de completude. Ação: o chamado é criado no sistema, os dados faltantes são pedidos e um executor é designado. Resultado: o chamado chega completo ao executor, sem idas e vindas para esclarecer coisas.
Dados: fichas de clientes, negócios, tarefas, histórico de contatos. Processamento: interpretação do pedido do gerente e do resultado da conversa. Ação: criar e atualizar uma ficha, registrar o resultado de um contato, criar uma tarefa, montar um resumo sobre um cliente antes de uma ligação. Resultado: o CRM é preenchido durante o trabalho, e não à noite de memória.
Dados: contratos, especificações, regulamentos, documentação técnica, arquivo de correspondência. Processamento: busca por sentido em vez de coincidência de palavras; a resposta é construída com os trechos encontrados. Ação: uma resposta com citação e referência ao documento, à página e à versão. Resultado: responder a uma pergunta sobre um contrato leva segundos e pode ser conferido na fonte.
Um bot não é um modelo só, mas várias partes conectadas. A separação tem valor prático: cada parte tem seu jeito de falhar, suas métricas e seu jeito de ser corrigida.
Os canais de conexão — o site e a área do cliente, mensageiros, e-mail, uma linha telefônica com reconhecimento de fala, o portal interno e os postos de trabalho dos funcionários. A lógica é a mesma em todos: o canal muda a forma da entrada, e não o que o bot pode fazer.
O bot não guarda seus documentos na memória — ele os pesquisa no momento da pergunta e responde com o que encontra. Por isso um regulamento atualizado passa a valer assim que é carregado, e não depois de o modelo ser retreinado, e por isso toda resposta tem uma fonte.
A etapa 2 é obrigatória: o bot responde dentro das permissões de quem perguntou. Um documento a que o funcionário não tem acesso no sistema não entra nem na busca nem na citação — caso contrário, o bot vira uma forma de contornar o sistema de acessos.
A primeira coisa montada é um conjunto de perguntas reais — de correspondência, chamados e chats internos. Com ele o bot é testado antes do lançamento: as respostas são conferidas com as fontes e os erros são analisados por causa. Só então o bot é aberto aos usuários, em geral primeiro a um grupo.
O principal risco de um bot de IA é uma resposta errada dita com segurança. Ele é eliminado não por promessas, mas pela construção do sistema: um conjunto limitado de operações, apoio obrigatório em fontes, limiares de confiança e regras explícitas de escalonamento.
O bot faz apenas o que está descrito no conjunto de ações dele, e dentro das permissões de quem perguntou. Todo o resto é indisponível, por mais que o usuário insista.
A resposta é montada com os documentos encontrados e os dados dos sistemas. Se não houver fonte, o bot diz que não sabe e passa a pergunta adiante — isso é comportamento normal, não uma falha.
Abaixo do limiar a resposta não é enviada ao cliente: ela vai a um operador como rascunho, junto com os materiais encontrados. Cada tema tem seu próprio limiar.
Escalonamento por regras: tema restrito, pergunta repetida, reação negativa, exigência do cliente. O operador recebe a conversa inteira e os materiais encontrados, em vez de começar do zero.
Uma ação irreversível — cancelar um pedido, mudar dados bancários, dar baixa em algo — só é executada depois de confirmação explícita e é gravada no registro junto com quem iniciou.
A parcela de conversas encerradas sem um humano, a parcela de escalonamentos, as avaliações dos usuários e conferências por amostragem das respostas. Os erros voltam para o conjunto de perguntas de teste.
O que o bot diz sobre si mesmo é registrado à parte: o usuário precisa entender que está falando com um software e saber como chamar uma pessoa. Isso é uma exigência sobre a interface, e não uma questão de configuração.
Um assistente interno difere de um bot para clientes pelos dados de origem: ele trabalha com informação corporativa e dentro das permissões de um funcionário específico. A mesma pergunta feita por um operador de armazém e por um diretor financeiro dá respostas diferentes — porque documentos diferentes estão disponíveis a cada um.
O que um assistente faz em um posto de trabalho:
Resultado: o funcionário gasta tempo com o trabalho, e não com procurar o documento certo, lembrar um regulamento e preencher formulários. O assistente não toma decisões pela pessoa — ele elimina a parte preparatória.

O assistente se conecta aos mesmos papéis dos sistemas contábeis: ele não cria um caminho de acesso paralelo. Documentos fora das permissões de um funcionário não entram nem na busca, nem nas citações, nem nas sugestões — e isso é verificado antes de a resposta ser montada, não depois.
As ações do assistente vão para o registro geral do sistema, ao lado das ações das pessoas. Em uma ficha fica visível que a tarefa foi criada pelo assistente a partir de uma conversa, e não que um registro apareceu sem autor.
O conhecimento corporativo raramente está em um lugar só: regulamentos em uma pasta, contratos em outra, documentação técnica em uma terceira, e metade das respostas na correspondência. Buscar por nome de arquivo não funciona aqui, porque uma pessoa não procura um documento, mas uma resposta.
Dados: regulamentos e ordens de serviço, contratos e aditivos, documentação técnica e de projeto, instruções, a base de chamados resolvidos, atas, cadastros, o arquivo de correspondência — cada um com dono e nível de acesso.
Processamento por IA: os documentos são divididos em trechos e cada trecho é indexado por sentido; a pergunta é confrontada com trechos, e não com títulos. A resposta é montada com o que foi encontrado e vem com citação e referência ao documento, à página e à versão.
Ação e resultado: um funcionário recebe uma resposta com fonte em segundos, em vez de sair perguntando aos colegas; os casos limítrofes são conferidos na citação; os documentos desatualizados ficam visíveis na hora — se a resposta veio de uma versão de dois anos atrás, isso está escrito na própria resposta.
Ela não substitui o sistema de gestão documental e não vira a fonte da verdade: um documento com validade jurídica fica onde foi assinado e onde é guardado. O índice é uma forma de encontrá-lo e citá-lo, e não uma cópia à parte vivendo vida própria.
Um chamado chega em formato livre e por qualquer canal: um e-mail, uma mensagem, um formulário do site, um telefonema, um arquivo anexado. Antes da adoção, uma pessoa o lê, transfere os dados para o sistema, determina o tipo e designa um executor — o que leva de alguns minutos a algumas horas de espera em fila.
Processamento por IA: determina-se o tipo do chamado, extraem-se campos — objeto, endereço, prazo, contato, número do contrato —, verifica-se a completude, avalia-se a urgência e o chamado é ligado ao cliente e ao histórico dele. O que faltar é pedido automaticamente pelo mesmo canal.
Ação: o chamado é criado no sistema com os campos preenchidos, um grupo ou executor é designado pelas regras, um prazo é definido e uma confirmação com número é enviada. Duplicatas sobre o mesmo assunto são vinculadas, em vez de gerarem um segundo chamado.
Resultado: o executor recebe um chamado completo e começa pelo trabalho, e não por esclarecimentos. O tempo entre a chegada e a designação deixa de depender de quem abriu a caixa comum e quando.
Uma tela do sistema: os dados são ilustrativos. Os chamados cujo tipo foi determinado com confiança abaixo do limiar chegam ao despachante com campos pré-preenchidos e um tipo sugerido — a designação continua com uma pessoa.
Dados
Analítica e previsão
Automação
Bots e assistentes
Um modelo só é útil quando a decisão dele chega ao sistema em que o trabalho é feito. Por isso a integração não é a etapa final de um projeto, mas a condição prévia dele: primeiro se sabe onde o resultado vai cair, depois o modelo é treinado.
A que a camada de IA se conecta:
O método de conexão é escolhido conforme o sistema, e não por hábito: uma API direta, troca por fila, webhooks em eventos, exportações de arquivo conforme programação, leitura de uma réplica do banco. Para sistemas sem interface aberta usa-se o método de troca que eles tiverem, inclusive arquivos.

| Hora | Operação | Resultado |
|---|---|---|
| 11:02 | Classificação de chamados → CRM | 148 |
| 11:05 | Previsão de demanda → pedido de compra | 1 204 |
| 11:07 | Leitura de notas de entrega → sistema contábil | 6 aguardando revisão |
| 11:09 | O serviço de armazém está indisponível | nova tentativa em 5 min |
Uma tela do sistema: os números são ilustrativos. A indisponibilidade do armazém não interrompe as outras trocas — as mensagens esperam na fila e saem quando a conexão é restabelecida.
Adotar IA significa trabalhar com os dados da empresa, então a pergunta de onde o modelo roda e do que sai do perímetro é resolvida antes de o projeto começar, e não depois do lançamento.
O ambiente é escolhido pela sensibilidade dos dados: infraestrutura própria, um servidor dedicado ou um serviço externo. Para parte das tarefas, modelos abertos em hardware próprio cobrem a necessidade por completo.
Se um modelo externo for usado, o conjunto de campos transmitidos é descrito de forma explícita. Dados pessoais e condições comerciais são anonimizados ou substituídos por identificadores antes do envio.
A camada de IA funciona dentro das permissões do usuário e não cria uma porta dos fundos para os dados. A verificação de acesso roda antes da busca e antes de a resposta ser montada.
O pedido, as fontes encontradas, a decisão do modelo e a ação executada são todos gravados no registro. Sem isso não há como apurar um caso contestado nem demonstrar que o sistema funcionou corretamente.
Decisões com consequências jurídicas ou financeiras ficam com uma pessoa. O modelo prepara o material e propõe uma opção, e a confirmação é registrada com o autor.
Os prazos de guarda de conversas, conjuntos de treino e dados intermediários são definidos de antemão. A exclusão mediante pedido alcança também os índices de busca, e não apenas a base de origem.
Um modelo sempre erra — a questão é com que frequência, onde exatamente e quanto isso custa. Por isso toda adoção tem dois conjuntos de números: a qualidade do próprio modelo e a mudança no processo. O primeiro interessa ao engenheiro, o segundo ao negócio, e eles não coincidem automaticamente.
O limiar de confiança é um botão de ajuste, não uma constante. Aumente-o e a empresa terá menos automação e menos erros; diminua-o e o contrário. O valor é escolhido pelo custo de um erro naquele processo específico.
Uma tela do sistema: os números são ilustrativos. Os três indicadores só se leem juntos: mais automação junto com uma parcela crescente de correções significa que o limiar foi baixado demais.
Um modelo não é uma entrega única. Os dados mudam: aparecem produtos novos, temas novos de chamados, formatos novos de documentos, fornecedores novos. Por isso o projeto prevê verificações regulares de qualidade sobre dados frescos, retreinamento conforme programação ou ao cruzar um limiar, e revisão dos casos em que uma pessoa corrigiu a decisão.
As correções dos operadores são o material de treino mais valioso: elas são reunidas em um conjunto à parte e usadas na rodada seguinte de treinamento. Assim o sistema melhora sobre o próprio trabalho, e não sobre dados alheios.
A ordem reflete as dependências: cada etapa se apoia no que surgiu na anterior. Pular a primeira etapa é o motivo mais comum de um projeto de IA terminar em uma demonstração.
Qual operação está sendo automatizada, quem a executa hoje, quais dados existem e em que estado, onde o resultado vai cair. O produto é uma linha de base em números e um critério de sucesso.
Conectar as fontes, limpar e rotular, montar uma base analítica para a tarefa. É aqui também que fica claro se há histórico suficiente para um modelo ou se os dados precisam ser acumulados antes.
Treino e verificação em um período separado, comparação com a linha de base, lançamento em modo de sugestão sobre parte do fluxo. O limiar de confiança é ajustado sobre as decisões reais dos operadores.
Integração com os sistemas, permissões e registros, monitoramento de qualidade e de deriva, retreinamento conforme programação, suporte. A extensão a processos vizinhos vem como etapas à parte, com medição.
Descreva o processo que você quer automatizar e quais dados já são coletados sobre ele. Vamos dizer o que dá para resolver aqui com regras e integração e onde um modelo é realmente necessário.