Chatbots internos com dados do ERP: IA conversacional

A demonstração é sempre convincente. Alguém escreve «quanto faturámos ao Cliente A no trimestre passado» e surge uma resposta fluente e bem formatada. Todos os presentes pensam de imediato em cinco perguntas que fariam. O projeto é aprovado.

Depois surgem dois problemas, e são o mesmo problema com roupa diferente. O primeiro é que a resposta tem de estar certa: não plausível, não aproximadamente certa, mas correta como tem de ser correto um valor num relatório de gestão, porque alguém vai agir com base nele. O segundo é que a resposta tem de estar certa para quem pergunta: um comercial que pergunta pela margem, um responsável de armazém que pergunta pela situação de crédito de um cliente e um analista financeiro que faz as mesmas perguntas não têm todos direito à mesma resposta.

Um chatbot sobre dados do ERP não é, portanto, um projeto de interface conversacional. É um projeto de recuperação de dados, permissões e verificação com uma interface conversacional por cima — e a ordem destas palavras é toda a diferença entre algo útil e algo que desinforma silenciosamente a sua empresa.

Porque é que isto importa

O ganho é genuíno e não tem propriamente a ver com comodidade. A maioria dos ERP do mid-market contém respostas que ninguém recupera, porque recuperá-las exige saber que pesquisa guardada executar, conhecimento concentrado em três ou quatro pessoas. Essas pessoas tornam-se um estrangulamento em perguntas de rotina, e as restantes ou adivinham ou trabalham a partir de uma folha de cálculo exportada que estava atualizada no mês passado. Tornar os dados efetivamente acessíveis é uma mudança real na forma como uma empresa opera.

O risco é proporcional. Um sistema que responde com fluência e ocasionalmente erra é mais perigoso do que um difícil de usar, porque os erros chegam com a mesma confiança das respostas corretas e não existe um momento natural de dúvida. Um comercial que indica um valor de margem a um cliente, ou um gestor que toma uma decisão de aprovisionamento com um número mal lido, não saberá que esta resposta em concreto foi uma das erradas.

E existe um risco de exposição fácil de criar por acidente. Um chatbot ligado com permissões amplas de conta de serviço dirá de bom grado a quem perguntar quais são os salários, as margens por cliente ou os preços dos fornecedores. A interface torna trivialmente acessíveis dados antes obscuros, o que é precisamente o objetivo, e isso significa que um controlo de acesso que era adequado quando as consultas exigiam perícia já não é adequado.

Vista rápida: tipos de pergunta e se devem ser permitidos

A distinção que importa está entre recuperação e raciocínio. As perguntas que se respondem obtendo um número e aplicando uma definição acordada são seguras. As que exigem interpretar porque algo aconteceu convidam a uma narrativa fluente que pode ser inteiramente construída, e os utilizadores não distinguem a diferença. Mantenha o sistema do lado da recuperação dessa linha e diga-o abertamente aos utilizadores.

O que funciona e sobre o que ser honesto

O que funciona:

Consultas sobre fontes definidas e determinísticas, em vez de interpretação livre. O chatbot associa a pergunta a uma de entre um conjunto curado de consultas parametrizadas — pesquisas guardadas, relatórios, métricas definidas. Se nenhuma consulta corresponder, di-lo. Isto é menos impressionante numa demonstração e dramaticamente mais fiável em produção.

Permissões herdadas do utilizador que pergunta, sempre. Cada consulta é executada com as permissões dessa pessoa no ERP, não com as de uma conta de serviço. É a decisão de desenho mais importante de todo o projeto e é a que mais vezes se adia por ser inconveniente.

Cada resposta mostra o seu percurso. O valor, a fonte, os filtros aplicados, o período e uma ligação ao registo ou relatório subjacente. Os utilizadores têm de poder verificar, e a presença de uma citação muda a forma como tratam o número — e para melhor.

Recusa explícita em vez de inferência. Quando a pergunta é ambígua ou não é suportada, o comportamento correto é dizê-lo e oferecer aquilo a que consegue responder. Um sistema que adivinha para parecer útil vai errar ocasionalmente e ser confiado uniformemente, que é a pior combinação.

Definições acordadas antes da entrada em produção. Se «rédito», «margem» ou «cliente ativo» significam coisas diferentes em três departamentos, o chatbot escolherá uma e apresentá-la-á como facto. Resolva primeiro as definições; o exercício vale a pena por si só.

Registar cada pergunta e cada resposta. Isto dá-lhe uma trilha de auditoria, uma visão do que as pessoas querem realmente saber e a evidência para detetar uma resposta sistematicamente errada antes de se propagar.

Sobre o que ser honesto:

A agregação é onde os erros se escondem. Uma consulta de registo único errada é evidente. Uma agregação subtilmente errada — um filtro que exclui intercompanhias, um limite de período desviado um dia, uma moeda não convertida — produz um número plausível que ninguém questiona. As consultas de agregação precisam de ser testadas contra relatórios de correção conhecida, e retestadas quando esses relatórios mudam.

Os utilizadores vão confiar em excesso num resultado fluente. É uma propriedade do meio, não da sua configuração. Mitigue com citações, declarações explícitas de âmbito e dizendo às pessoas com clareza para que é que o sistema não serve. Conte com repetir essa mensagem.

Vai expor os seus problemas de qualidade de dados como erros visíveis para o utilizador. Registos de cliente duplicados fazem com que uma consulta de cliente devolva resultados parciais. Dados de artigo inconsistentes produzem respostas incompletas. O chatbot não cria estes problemas; torna-os públicos.

Consolidar não é somar, e o sistema não o saberá. Os valores de grupo exigem lógica de eliminação e de conversão. A não ser que essa lógica seja explícita e utilizada, as perguntas entre entidades devem ser bloqueadas em vez de respondidas de forma aproximada.

O alargamento descontrolado do âmbito é o principal modo de falha. Começa com o estado das encomendas e perguntas definitórias, funciona bem, e depois alguém pede previsões. Os tipos de pergunta prospetiva e explicativa são onde a confiança se perde, e o limite tem de ser sustentado deliberadamente.

Quadro de decisão: desenhá-lo com segurança

Percorra por ordem. Pare na primeira correspondência.

1. Consegue cada consulta ser executada com as permissões próprias do utilizador que pergunta?
Se não, resolva isto antes de tudo o resto. Um chatbot sobre uma conta de serviço partilhada é uma exposição de dados com uma interface amigável, e será usado por pessoas cujo acesso antes estava limitado pela incapacidade de escrever consultas e não por política.

2. As suas métricas-chave têm cada uma uma única definição acordada?
Se não, resolva-as. Rédito, margem, cliente ativo, entrega a horas. Caso contrário, o chatbot apresentará a definição de um departamento como a resposta da empresa.

3. Definiu o domínio de perguntas suportado e o que acontece fora dele?
Escreva o limite, implemente uma recusa explícita fora dele e comunique-o aos utilizadores. Comece estreito — consultas de estado, agregações definidas, perguntas de política e de processo.

4. Cada resposta transporta a sua fonte, os filtros e o período?
Se não, acrescente isto antes do lançamento e não depois. É o que torna a verificação possível e o que muda o comportamento do utilizador para melhor.

5. Testou as respostas de agregação contra relatórios de correção conhecida?
Construa um conjunto de testes de perguntas com respostas verificadas e volte a executá-lo sempre que os relatórios subjacentes ou a configuração mudem. É uma bateria de regressão, e é o que evita o desvio silencioso.

6. Cada interação é registada com o utilizador, a pergunta, a consulta executada e a resposta?
Implemente isto desde o primeiro dia. É a sua trilha de auditoria e a sua melhor fonte de informação sobre o que construir a seguir.

7. Tudo isto e os utilizadores continuam a não o adotar?
Normalmente o domínio suportado é demasiado estreito para ser útil, ou as respostas são corretas mas mais lentas do que perguntar a um colega. Veja as perguntas registadas que recusou — é esse o seu roteiro.

Custo e esforço indicativos

Pressupõe uma instância de ERP e um domínio inicial de perguntas definido. A consolidação multientidade, ou a extensão a fontes documentais não estruturadas, alarga isto materialmente. Peça um orçamento para uma estimativa delimitada.

Perguntas frequentes

Pode gerar consultas dinamicamente em vez de usar uma biblioteca curada?
Tecnicamente sim, e não o recomendaríamos para dados financeiros e operacionais à escala do mid-market. Uma consulta gerada que está subtilmente errada produz um número plausível sem qualquer sinal de erro. Uma biblioteca curada é menos flexível e as suas falhas são visíveis, o que para números sobre os quais as pessoas agem é a troca certa.

Como impedimos que responda a perguntas a que não deve?
Duas camadas: permissões, para que não consiga recuperar o que o utilizador não pode ver; e delimitação do domínio, para que categorias inteiras — dados pessoais, perguntas prospetivas, análise explicativa — fiquem excluídas por desenho em vez de filtradas caso a caso.

E quanto à alucinação?
Ancorar cada resposta num resultado recuperado e exigir uma citação cobre a maior parte do risco nas perguntas de recuperação. O risco residual está na forma como os resultados são resumidos e nas perguntas explicativas, em que o sistema é convidado a construir uma narrativa — razão pela qual essas devem ser excluídas em vez de mitigadas.

Deve escrever no ERP além de ler?
Não inicialmente, e o modo apenas de leitura é uma posição permanente defensável para uma interface conversacional. As ações de escrita pertencem a agentes com limites de autoridade definidos, trilhas de auditoria e vias de escalamento — o desenho discutido noutros pontos desta série — e não a uma janela de chat onde a intenção é inferida a partir da linguagem natural.

Como medimos se funciona?
Perguntas feitas, perguntas recusadas, exatidão verificada contra o seu conjunto de testes e a alteração na procura sobre as duas ou três pessoas que antes respondiam a estas perguntas. A última é o verdadeiro caso de negócio.

Com que rapidez pode o chatbot ser realmente ligado aos dados do ERP em direto?
A ligação costuma ser rápida — um parceiro certificado como Stacksync pode ter a sincronização em tempo real e governada entre o ERP e a camada de dados do chatbot a funcionar em semanas. Conseguir que o chatbot responda apenas com aquilo que realmente tem permissão para ver, como se explica acima, é a parte que precisa de tempo real de conceção.

Fecho — Próximos passos

Um chatbot interno sobre dados do ERP é o item mais demonstrável e mais mal compreendido desta série. O que o faz funcionar quase nada tem a ver com a conversa: são as permissões por utilizador, as definições de métricas acordadas, as consultas determinísticas curadas, as fontes visíveis e um limite que o sistema se recusa a atravessar.

Um ponto de partida útil que custa uma semana: reúna as vinte perguntas que as suas equipas de finanças e de operações recebem efetivamente com mais frequência. Separe-as em perguntas de recuperação e perguntas de raciocínio. A primeira pilha é o seu âmbito inicial, e normalmente é suficientemente grande para justificar o projeto por si só.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora de NetSuite que serve clientes mid-market em toda a Ibéria. Especializa-se em ligar sistemas CRM e ERP para fluxos order-to-cash sem atritos, construindo pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas comerciais e financeiras. Como partner oficial de implementação da Stacksync, Bruno desenha e implementa agentes de IA em plataformas de integração para tratar o encaminhamento de exceções, o processamento de documentos e a reconciliação — transformando fluxos de encomendas fragmentados em sistemas fiáveis e com automonitorização.

LinkedIn: https://www.linkedin.com/in/brunogd

Fontes

Os URL são a nível de editor e devem ser verificados antes da publicação.

• Oracle NetSuite, documentação de perfis, permissões e pesquisas guardadas — https://docs.oracle.com/en/cloud/saas/netsuite/
• NIST, AI Risk Management Framework — validade, fiabilidade e transparência — https://www.nist.gov/itl/ai-risk-management-framework
• Comissão Europeia, EU AI Act — obrigações de transparência — https://digital-strategy.ec.europa.eu
• Comité Europeu para a Proteção de Dados, orientações sobre minimização de dados e controlo de acesso — https://www.edpb.europa.eu
• Experiência da Atypical Tech em projetos de ERP mid-market e implementações conversacionais na Ibéria
• Stacksync, blog da plataforma de integração e sincronização em tempo real — https://www.stacksync.com/blog