Como ligar os sistemas da empresa com inteligência artificial?

Segundo a Mesterséges Intelligencia Központ Kft., empresa de desenvolvimento de software de Budapeste, integrando o modelo de linguagem nos fluxos de trabalho existentes através de uma API: os sistemas mantêm-se, e o modelo extrai, classifica, resume e redige.

Em resumo: não é preciso substituir os sistemas existentes: o modelo de linguagem recebe tarefas e dados através de uma interface de programação, e o resultado volta para onde se trabalha com ele, seja o CRM, o ERP ou o cliente de e-mail. Vale a pena começar por uma única tarefa, bem mensurável, passar apenas os dados necessários e, onde um erro custa dinheiro, deixar que seja uma pessoa a aprovar o passo.

O que significa isto na prática?

O grande modelo de linguagem (large language model, LLM) interpreta e produz texto. No uso empresarial, não é uma janela de conversa à parte, para onde os colaboradores copiam texto e de onde o voltam a copiar, mas um serviço que os próprios programas da empresa chamam através de uma interface de programação, ou seja, de uma API (application programming interface). O modelo recebe os dados de que a tarefa precisa, faz o trabalho linguístico, e o programa encaminha o resultado para o sistema certo, verificado e registado.

Há cinco operações linguísticas que surgem em quase todas as integrações:

• Extração: uma fatura, uma guia de remessa ou um e-mail recebido transformam-se em dados estruturados (cliente, linhas, prazo).
• Classificação: o sistema decide se um e-mail é uma reclamação, um pedido de proposta ou uma questão de faturação, e coloca-o na fila certa.
• Resumo: uma longa troca de e-mails com um cliente transforma-se num histórico de poucas frases no CRM.
• Redação: é elaborado um rascunho de resposta, um texto de proposta ou uma descrição de produto, que um colaborador revê.
• Resposta: o colaborador faz perguntas em linguagem corrente aos documentos ou aos dados da empresa.

Se o sistema tiver não só de responder, mas também de agir de forma autónoma, em vários passos, já se trata de um agente de IA; a diferença entre as duas soluções é tratada no artigo Chatbot ou agente de IA?. Se o modelo tiver de responder a partir dos próprios documentos da empresa, o método é o RAG, que apresentamos num artigo à parte.

Três padrões de integração

API e webhook

A maioria dos sistemas empresariais (CRM, ERP, loja online, programa de faturação, e-mail) tem uma API, através da qual outro programa pode ler dados do sistema ou escrever dados nele. O webhook é o inverso: o próprio sistema notifica um endereço definido de antemão quando acontece alguma coisa, por exemplo quando chega uma encomenda ou um e-mail. A integração de IA mais simples consiste nestes dois elementos: um evento desencadeia um serviço próprio, que chama a API do modelo de linguagem, verifica o resultado e depois o escreve no sistema de destino através da API deste. Neste padrão, o modelo não tem acesso direto a nenhum sistema da empresa; é o nosso código que faz tudo, e é aí que se decide o que pode chegar ao modelo e o que pode voltar.

Chamada de funções (tool use)

A chamada de funções (na Anthropic, tool use, ou seja, utilização de ferramentas) permite que o modelo decida ele próprio quando precisa de um dado ou de uma operação. O programador descreve ao modelo as funções disponíveis, por exemplo «consultar o estado de uma encomenda», e o modelo, com base na pergunta, devolve uma chamada estruturada com os parâmetros necessários. Segundo a documentação dos três grandes fornecedores, a função não é executada pelo modelo, mas pela aplicação: na documentação da OpenAI, o código corre do lado da aplicação; segundo a Anthropic, as ferramentas próprias são executadas pela aplicação; e a documentação do Google Gemini afirma que o próprio modelo não executa a função. Daqui decorre o princípio de conceção mais importante: a verificação das permissões reside no nosso código, e não depende da boa vontade do modelo. A OpenAI e a Anthropic oferecem também um modo estrito (strict), que garante que os parâmetros da chamada seguem exatamente o esquema indicado; a documentação da Anthropic alerta, no entanto, que, quando falta um dado, o modelo por vezes inventa um valor de aparência plausível, pelo que o código também tem de verificar os parâmetros.

Model Context Protocol (MCP)

O MCP é um protocolo aberto que, segundo a sua especificação, oferece uma forma uniforme de as aplicações que usam modelos de linguagem se ligarem a fontes de dados e ferramentas externas. Tem três intervenientes: o anfitrião (host), ou seja, a aplicação que usa o modelo de linguagem; o cliente que corre dentro dela; e o servidor, que oferece dados (resources), modelos de instruções (prompts) e ferramentas que podem ser chamadas (tools). As mensagens usam o formato JSON-RPC 2.0; a versão atual da especificação é a que tem a designação 2026-07-28 (verificado em 17 de outubro de 2026).

A vantagem do MCP é que basta escrever uma vez um servidor para um sistema, e várias aplicações de IA podem depois usá-lo. A API da Anthropic, a API da OpenAI e a API do Gemini conseguem ligar-se a servidores MCP remotos (verificado em 17 de outubro de 2026). O protocolo não resolve todas as questões de segurança: segundo os princípios de segurança da especificação, a aplicação anfitriã tem de pedir o consentimento explícito do utilizador antes de cada chamada de ferramenta, mas o próprio protocolo não consegue impor isso; tem de ser quem o implementa a incorporá-lo. A OpenAI alerta também que um servidor malicioso pode exfiltrar dados sensíveis que entrem no contexto do modelo. Num ambiente empresarial, por isso, só entram em consideração servidores próprios ou de um fornecedor de confiança.

Padrão	Para que serve	A que prestar atenção
API e webhook	processos fixos e previsíveis: cada e-mail e cada fatura segue o mesmo caminho	cada passo tem de ser planeado de antemão, incluindo o tratamento de erros e as novas tentativas
Chamada de funções	quando o modelo tem de obter dados ou iniciar uma operação consoante a pergunta	o conjunto de funções e as suas permissões; o modelo também pode fornecer um parâmetro errado
MCP	quando várias aplicações de IA têm de aceder ao mesmo sistema	só servidores de confiança; aprovação antes das chamadas de ferramentas

Para que pode ser usada? Tarefas típicas

Área	Tarefa	Padrão habitual	Aprovação humana
Documentos	extração dos dados de faturas, guias de remessa e contratos, e comparação com a encomenda	API, com saída num esquema fixo	em caso de divergência ou de extração incerta
E-mail	classificação e reencaminhamento das mensagens recebidas, rascunho de resposta	webhook e API	antes do envio da resposta
CRM	resumo do histórico do cliente, sugestão do passo seguinte	chamada de funções com acesso de leitura	não é necessária, porque é apenas uma sugestão
ERP	perguntas sobre os dados em linguagem corrente, elaboração de relatórios	chamada de funções com acesso de leitura	se a operação alterar dados
Loja online	descrições de produtos, traduções, pesquisa mais precisa	API	antes da publicação do texto
Conhecimento interno	perguntas e respostas a partir de regulamentos e manuais	RAG	não é necessária, se a resposta indicar a fonte

Pode ler mais sobre os nossos serviços na página Integração de IA, sobre os processos automatizados que abrangem vários sistemas na página Automatização de processos e sobre a IA integrada nos sistemas ERP e CRM na página Software empresarial.

Fluxo de dados e proteção de dados: o que vai para onde?

A integração de IA é também tratamento de dados. O primeiro passo da conceção é, por isso, um diagrama simples do fluxo de dados: que campos saem dos sistemas da empresa, para que fornecedor vão, em que região são tratados, durante quanto tempo o fornecedor os guarda e o que volta. As condições dos fornecedores mudam com frequência; o que se segue baseia-se na documentação dos próprios fornecedores (verificado em 17 de outubro de 2026).

O que dizem os fornecedores?

• OpenAI: segundo a documentação sobre o tratamento de dados, os dados enviados através da API não são usados para treinar modelos, a menos que o cliente o autorize expressamente. Os registos de monitorização de abusos são conservados, por predefinição, durante um máximo de 30 dias. O armazenamento e o tratamento de dados na Europa (EEE e Suíça) estão disponíveis mediante aprovação separada, com determinadas definições de conservação de dados.
• Anthropic: segundo o seu centro de privacidade, as entradas e as saídas dos produtos comerciais, incluindo a API, não são usadas, por predefinição, para treinar modelos e, no caso da API, são, regra geral, apagadas no prazo de 30 dias, com as exceções enumeradas. Na própria API da Anthropic, o local do tratamento pode ser, segundo a documentação, «us» ou «global»; no Amazon Bedrock e no Google Cloud, a região é determinada pelo ponto de acesso (endpoint) escolhido.
• Google: segundo as condições da API do Gemini, nos serviços pagos a Google não usa os prompts e as respostas para melhorar os seus produtos, e só os regista durante um período limitado, para detetar abusos; a utilizadores residentes no EEE, na Suíça e no Reino Unido só podem ser oferecidas aplicações assentes nos serviços pagos. Segundo a descrição sobre a residência dos dados do Google Cloud Vertex AI, no ponto de acesso multirregional da UE o tratamento permanece dentro da UE, ao passo que no ponto de acesso global não existe essa garantia; a disponibilidade de cada modelo em cada região varia de modelo para modelo.

Os aspetos do RGPD

Se chegarem dados pessoais ao modelo, o tratamento está sujeito ao RGPD. Nesse caso, o fornecedor do modelo é normalmente um subcontratante, pelo que é necessário celebrar com ele um contrato nos termos do artigo 28.º, n.º 3, do Regulamento Geral sobre a Proteção de Dados; o artigo 5.º impõe a minimização dos dados, e o artigo 25.º menciona a pseudonimização como exemplo entre os meios de proteção de dados desde a conceção. Na prática, isto significa o seguinte:

• só chegam ao modelo os campos de que a tarefa precisa;
• sempre que possível, os nomes e os identificadores são ocultados ou pseudonimizados, e a resposta é associada de novo aos dados no nosso próprio sistema;
• o modelo só pode ver aquilo que o utilizador que faz a pergunta também pode ver;
• registamos quem chamou o modelo, quando e com que dados.

Sobre as transferências de dados para fora da UE, a transparência e o AI Act escrevemos no artigo AI Act e RGPD num chatbot empresarial. Trata-se de informação, não de aconselhamento jurídico.

Onde é necessária aprovação humana?

O modelo de linguagem pode enganar-se e, segundo o guia de avaliação da OpenAI, nem sempre produz o mesmo resultado para a mesma entrada. Por isso, vale a pena conceber o processo de forma a que um erro do modelo não possa causar danos. Distinguimos três níveis:

• Sugestão: o modelo apenas sugere (resume, redige um rascunho, propõe uma categoria), e a decisão e a operação cabem a uma pessoa. Aqui, o preço de um erro é baixo.
• Operação preparada: o modelo prepara o passo, por exemplo preenche a reclamação ou escreve a resposta, e um colaborador aprova-o ou corrige-o com um clique.
• Operação automática: o passo corre sem aprovação, mas apenas com permissões restritas, limites de volume, registo e verificações por amostragem.

A regra prática: onde um erro custa dinheiro, afeta um cliente ou não pode ser revertido (um pagamento, uma fatura, um contrato, um e-mail enviado a um cliente), é uma pessoa que aprova o passo. A lista de riscos do OWASP GenAI Security Project diz o mesmo sobre a liberdade de ação excessiva (Excessive Agency): o modelo só recebe as ferramentas de que a sua tarefa precisa, com as permissões mais restritas possíveis, as operações de grande impacto são aprovadas por uma pessoa, a operação corre com as permissões do próprio utilizador e cada passo fica registado.

Um risco à parte é a injeção de prompts (prompt injection): quando o modelo lê conteúdo externo, como um e-mail recebido, um documento carregado ou uma página web, este pode conter texto que tenta influenciá-lo como se fosse uma instrução. Contra isso, o OWASP recomenda o privilégio mínimo necessário, a aprovação humana antes das operações privilegiadas e o tratamento do conteúdo externo em separado, assinalado como não fiável.

Testes e monitorização

Uma integração de IA não é boa por convencer numa demonstração, mas por trabalhar comprovadamente bem com o material real da empresa. Segundo o guia de avaliação da OpenAI, os dados de teste devem incluir também casos típicos, extremos e deliberadamente enganadores, e a avaliação deve voltar a ser executada a cada alteração; a Anthropic recomenda critérios de sucesso concretos e mensuráveis e um conjunto de testes que reflita as tarefas reais. É assim que o organizamos:

• Conjunto de avaliação: amostras reais, anonimizadas se necessário, com o resultado esperado, por exemplo os campos a extrair ou a categoria correta.
• Medição antes da entrada em produção: comparamos os modelos e os prompts candidatos neste conjunto.
• Nova medição a cada alteração: perante um novo prompt, uma nova versão do modelo ou um novo tipo de documento.
• Registo: a entrada, a saída, o modelo e a versão do prompt, bem como a correção humana. O registo é também a fonte dos próximos casos de avaliação.
• Monitorização: taxa de erros, proporção de correções humanas, tempo de resposta e consumo de tokens, com alertas.

Os modelos não duram para sempre: tanto a Anthropic como a OpenAI retiram regularmente os modelos mais antigos e avisam os clientes com antecedência; um pedido enviado a um modelo retirado devolve um erro. Por isso, colocamos o modelo numa camada separada, e medimos cada mudança no mesmo conjunto de avaliação antes de ela entrar em produção.

Que modelo escolher?

Não há nenhum modelo igualmente bom em todas as tarefas, pelo que a escolha é uma questão de medição, e não de fidelidade a uma marca. Os nossos critérios:

• a qualidade do texto em húngaro nas amostras da própria empresa;
• a natureza da tarefa: texto, documento digitalizado, imagem ou tabela;
• a fiabilidade da chamada de funções e da saída estruturada;
• a velocidade e a tarifa de utilização para o volume esperado;
• as condições de tratamento de dados e o local do tratamento;
• a disponibilidade e o ciclo de vida do modelo.

É frequente vários modelos trabalharem dentro de um mesmo sistema: um modelo mais rápido e mais pequeno para a classificação, e um mais potente para os textos complexos. Como o modelo está numa camada separada, a decisão pode ser alterada mais tarde.

De que depende o custo?

O custo tem duas partes. O preço do desenvolvimento decorre do tamanho funcional, que medimos em pontos de função COSMIC; o método está descrito na página Preços. O custo de funcionamento depende da utilização: os fornecedores faturam em função da quantidade de texto processado e gerado, ou seja, do número de tokens e, segundo a descrição da Anthropic, também as descrições de ferramentas passadas ao modelo contam como tokens de entrada. O custo de funcionamento é influenciado por:

• o número e o tamanho dos documentos e e-mails processados;
• quantas chamadas ao modelo cabem a um processo (um agente que trabalha em vários passos significa várias chamadas);
• o modelo escolhido;
• o tamanho do contexto e das descrições de ferramentas passados ao modelo;
• as definições especiais, por exemplo o tratamento geograficamente restrito, que os fornecedores podem cobrar a uma tarifa mais elevada.

Estimamos o custo de funcionamento na fase de conceção, com amostras reais da empresa, e ponderamo-lo também na escolha do modelo.

Passo a passo: como começar

1. Escolha de uma tarefa: um trabalho frequente, de natureza linguística, com um objetivo mensurável, por exemplo a classificação das reclamações recebidas.
2. Desenho do fluxo de dados: de onde vêm os dados, o que pode ir para o modelo, para onde vai o resultado e quem o aprova.
3. Amostras e conjunto de avaliação: exemplos reais e anonimizados, com o resultado esperado.
4. Protótipo: comparação dos modelos candidatos nas amostras, ainda sem ligação em produção.
5. Ligação: API, webhook, chamada de funções ou MCP, com permissões, tratamento de erros e registo.
6. Funcionamento piloto: num círculo restrito, com aprovação humana de cada passo; aprendemos com as correções.
7. Expansão e operação: onde a medição o justificar, o círculo de aprovação é reduzido; a monitorização e as mudanças de modelo são contínuas.

Erros típicos

• Uma janela de conversa em vez de uma integração: os colaboradores copiam dados à mão para uma interface de IA genérica, pelo que os dados saem da empresa sem controlo e nada é mensurável.
• Demasiadas permissões: o modelo tem acesso a tudo aquilo a que a conta de integração tem acesso.
• Sem conjunto de avaliação: a qualidade é decidida por impressão, e a mudança de modelo por palpite.
• O modelo fixado no código: quando o modelo é retirado, toda a integração tem de ser reescrita.
• A proteção de dados no fim: o diagrama do fluxo de dados e o contrato de subcontratação são muito mais difíceis depois.
• Tudo ao mesmo tempo: cinco processos num só projeto, sem medição, e nenhum chega a ficar realmente concluído.

Perguntas frequentes

Que modelo escolher?

Aquele que, comprovadamente, tem o melhor desempenho na tarefa em causa com as amostras da própria empresa, com uma tarifa aceitável e condições de tratamento de dados adequadas. Trabalhamos com os modelos da OpenAI, da Anthropic e da Google, comparamos os candidatos com os exemplos da empresa e, como o modelo está numa camada separada, a decisão pode ser alterada mais tarde.

É seguro enviar dados da empresa para um serviço de IA?

Com uma conceção adequada, sim, mas não por si só. Segundo a sua própria documentação, as API empresariais dos grandes fornecedores não usam, por predefinição, os dados enviados para treinar modelos (verificado em 17 de outubro de 2026), mas o prazo e o local de armazenamento variam consoante o fornecedor e as definições. Cabe à empresa garantir que só saem os dados necessários, que os dados pessoais são, sempre que possível, pseudonimizados, e que existem um contrato de subcontratação e um local de tratamento escolhido de forma consciente. Trata-se de informação, não de aconselhamento jurídico.

É preciso substituir os nossos sistemas existentes?

Não. A integração assenta na API, nos webhooks, na base de dados ou nas exportações de ficheiros dos sistemas existentes, e o resultado volta para onde já se trabalhava. Se um sistema antigo não tiver interface de programação, analisamos de que forma é possível aceder aos seus dados em segurança.

O que é o MCP?

O Model Context Protocol é um protocolo aberto que liga, de forma uniforme, as aplicações que usam modelos de linguagem a fontes de dados e ferramentas externas. É útil quando várias aplicações de IA acedem ao mesmo sistema. Num ambiente empresarial, convém usá-lo apenas com servidores de confiança e com aprovação antes das chamadas de ferramentas.

O que acontece se a IA se enganar?

Contamos com isso, por isso concebemos o processo de forma a que o erro não cause danos. O código verifica a saída (o esquema e as regras de negócio, por exemplo se o total da fatura corresponde à soma das linhas), antes de um passo arriscado é uma pessoa que aprova, os casos incertos vão para um colaborador, e tudo fica registado. Os erros detetados são acrescentados ao conjunto de avaliação, pelo que a correção é mensurável.

Como podemos ajudar?

Ligamos com inteligência artificial tudo o que existe: integramos os modelos de linguagem da OpenAI (ChatGPT), da Anthropic (Claude) e da Google (Gemini) nos sistemas existentes das empresas. A primeira consulta é gratuita; medimos o tamanho do desenvolvimento em pontos de função COSMIC, e daí resultam a proposta e o calendário. A pedido, assinamos um acordo de confidencialidade (NDA) e, após a entrega, asseguramos também a operação e a manutenção, incluindo a monitorização do funcionamento do modelo. O código-fonte e os direitos de utilização regem-se pelo contrato.

Pode ler os pormenores na página Integração de IA. Se tem um processo que gostaria de ligar com inteligência artificial, escreva-nos através dos contactos indicados na página Contacto.

Fontes

• OpenAI: Function calling
• OpenAI: Data controls in the OpenAI platform
• OpenAI: MCP servers
• OpenAI: Evaluation best practices
• OpenAI: Deprecations
• Anthropic: Tool use with Claude
• Anthropic: Data residency
• Anthropic: Define success criteria and build evaluations
• Anthropic: Model deprecations
• Anthropic Privacy Center: Is my data used for model training?
• Anthropic Privacy Center: How long do you store my organization's data?
• Google Gemini API: Function calling
• Google: Gemini API Additional Terms of Service
• Google Cloud Vertex AI: Data residency
• Model Context Protocol: Specification, 2026-07-28
• OWASP GenAI Security Project: LLM06:2025 Excessive Agency
• OWASP GenAI Security Project: LLM01:2025 Prompt Injection
• EUR-Lex: Regulamento (UE) 2016/679 (Regulamento Geral sobre a Proteção de Dados, RGPD)