zkAPI é uma solução tecnológica de privacidade que aplica provas de conhecimento zero (Zero-Knowledge Proof, ZKP) ao controlo de acesso a API e à verificação de pagamentos. O seu objetivo é reduzir a exposição direta das identidades, contas e registos de pagamento dos utilizadores quando acedem a serviços online, como modelos de IA. Ao contrário dos modelos de acesso tradicionais, que dependem de contas verificadas, chaves API e sistemas de faturação centralizados, o zkAPI procura permitir que os utilizadores comprovem, por meios criptográficos, que dispõem de direitos de acesso válidos ou de credenciais de pagamento, sem divulgarem a sua identidade completa ao prestador do serviço.
À medida que os agentes de IA, as aplicações automatizadas e os serviços de modelos com pagamento por utilização continuam a desenvolver-se, os pagamentos de API estão a tornar-se uma infraestrutura importante para a economia digital. Embora os modelos de faturação tradicionais sejam maduros, geralmente exigem que os prestadores de serviços conservem registos de contas, pedidos e pagamentos durante períodos prolongados, facilitando a associação de comportamentos dos utilizadores. As provas de conhecimento zero oferecem uma nova abordagem técnica a este problema: separar, até certo ponto, as credenciais de pagamento da utilização efetiva do serviço, mantendo as capacidades necessárias de verificação de autorização e prevenção de abusos.
Este artigo começa pelo conceito de zkAPI e explica como as provas de conhecimento zero podem ser utilizadas para autorizar o acesso a API de IA, verificar credenciais de pagamento e gerir quotas de utilização. Analisa também os potenciais papéis dos contratos inteligentes da Ethereum, dos pagamentos on-chain e das tecnologias de privacidade. Além disso, o artigo aborda a diferença entre pagamentos anónimos e anonimato completo, bem como as limitações técnicas e comerciais que o zkAPI enfrenta em implementações reais.
zkAPI é uma solução técnica que explora a utilização de provas de conhecimento zero para o acesso a API, a verificação de identidade e a autorização de pagamentos. Procura reduzir a exposição das informações de identidade e pagamento dos utilizadores quando utilizam serviços de IA.
As API de IA tradicionais dependem geralmente de contas, chaves API e sistemas de faturação centralizados, permitindo aos prestadores de serviços associar registos de pedidos a contas específicas.
As provas de conhecimento zero permitem aos utilizadores comprovar que reúnem as condições para aceder a um serviço ou que dispõem de capacidade de pagamento suficiente, sem divulgar todas as informações subjacentes utilizadas na verificação.
A Ethereum e as suas redes de camada 2 podem fornecer infraestrutura de pagamento, contratos inteligentes e verificação de credenciais para soluções relacionadas. No entanto, isto não significa que os pedidos de inferência de IA ou todas as informações das transações recebam automaticamente proteção de privacidade.
As aplicações reais de zkAPI ainda precisam de resolver questões como a reutilização de credenciais, a gestão de quotas, os pedidos abusivos, os custos de geração de provas e a faturação do lado do servidor.
zkAPI é um protocolo de pagamento de API centrado na privacidade, desenvolvido em conjunto pelo Open Anonymity Project e pela Ethereum Foundation. Foi concebido para permitir aos utilizadores pagar por modelos de IA e outros serviços com pagamento por utilização através de provas de conhecimento zero, sem associar diretamente cada pedido de API à sua identidade real ou ao endereço de financiamento on-chain. Em 1 de outubro de 2026, a Ethereum Foundation anunciou o lançamento do zkAPI na rede principal da Ethereum e publicou implementações para o cliente, o servidor e o contrato inteligente. O projeto teve origem na conceção ZK API Usage Credits, anteriormente proposta por Vitalik Buterin e Davide Crapis, responsável pela equipa dAI da Ethereum Foundation.
Os serviços tradicionais de API de IA utilizam habitualmente chaves API para associar os pedidos dos utilizadores a contas, que, por sua vez, estão ligadas a cartões bancários ou a outros métodos de pagamento. À medida que os utilizadores continuam a utilizar os modelos, os prestadores de serviços podem combinar o histórico de prompts, os horários de utilização, os montantes gastos e as informações das contas em registos de longo prazo. Mesmo que os utilizadores não forneçam ativamente os seus nomes nos prompts, a associação contínua às informações das contas pode criar um perfil de utilização relativamente completo. Nas aplicações de IA que envolvem investigação e desenvolvimento empresarial, análise financeira pessoal ou outras informações sensíveis, este tipo de associação de dados pode gerar preocupações adicionais de privacidade.
O zkAPI procura alterar não os próprios modelos de IA, mas o método de autorização de pagamentos utilizado pelos serviços de modelos. Os utilizadores começam por depositar fundos num contrato inteligente da Ethereum e, depois, utilizam uma prova de conhecimento zero para demonstrar ao servidor de pagamentos que dispõem de crédito suficiente. O servidor pode confirmar a elegibilidade para pagamento sem saber qual o depósito específico que suporta o pedido atual. Ao mesmo tempo, o prestador de serviços de IA pode processar os prompts enviados pelo utilizador sem conhecer a identidade de financiamento on-chain associada ao pedido.
Assim, o objetivo central do zkAPI é impedir a associação entre as identidades de pagamento e os registos de utilização de API, e não cifrar automaticamente ou anonimizar por completo todos os pedidos de IA. Esta distinção é fundamental para compreender o valor técnico do protocolo.
Uma prova de conhecimento zero é uma tecnologia criptográfica que permite a uma parte provar a outra, responsável pela verificação, que uma afirmação é verdadeira, sem divulgar todas as informações secretas utilizadas para gerar a prova. Por exemplo, um utilizador pode provar que dispõe de fundos suficientes para pagar um serviço sem revelar a credencial específica de saldo privado de onde provêm esses fundos.
No zkAPI, depois de os utilizadores depositarem ETH ou outros ativos suportados num contrato inteligente Vault na Ethereum, o sistema representa o saldo disponível através de uma Private Note. Uma Note pode ser entendida como uma credencial digital de pagamento controlada pelas informações secretas do utilizador. O protocolo utiliza compromissos criptográficos para registar credenciais válidas e organiza esses compromissos numa árvore de Merkle. Isto permite aos utilizadores provar que as suas credenciais pertencem a um conjunto válido, sem revelar qual a credencial específica que detêm.
Quando um utilizador precisa de fazer uma chamada a uma API de IA, o cliente local gera uma prova de conhecimento zero que demonstra que a Note correspondente é válida, dispõe de capacidade de pagamento suficiente e cumpre as condições de utilização especificadas pelo protocolo. Depois de verificar a prova, o servidor de pagamentos pode emitir uma chave API temporária para o utilizador. Este processo não exige que o servidor obtenha as informações secretas originais do utilizador ou associe diretamente cada pedido a um endereço público de financiamento.
Para impedir que o mesmo saldo seja utilizado repetidamente, o zkAPI introduz um mecanismo de Nullifier. Um Nullifier é um identificador único gerado a partir de informações secretas e utilizado para detetar se o mesmo crédito disponível foi utilizado mais do que uma vez. Se o sistema detetar um Nullifier duplicado, pode identificar um possível comportamento de gasto duplo sem divulgar a identidade completa ou os registos de financiamento do utilizador. A implementação oficial utiliza componentes técnicos que incluem provas de conhecimento zero Groth16, a curva BN254, a função de hash Poseidon e árvores de Merkle.

O processo do zkAPI pode ser dividido em cinco etapas: financiamento, prova de pagamento, autorização temporária, chamada do modelo e faturação final. Ao contrário dos sistemas que iniciam uma transação on-chain para cada pedido de API, o zkAPI permite aos utilizadores depositar fundos antecipadamente na Ethereum e, depois, concluir várias autorizações de acesso a API através de provas off-chain, evitando a necessidade de esperar pela confirmação da blockchain sempre que fazem uma chamada a um modelo.
Primeiro, o utilizador deposita fundos num contrato Vault na Ethereum e recebe um saldo disponível representado por uma Private Note. Quando precisa de fazer uma chamada a um modelo de IA, o cliente local gera uma prova de pagamento e envia-a para o servidor zkAPI. Depois de verificar a validade da prova, o servidor gera uma chave API temporária para a sessão atual, com um prazo de caducidade e um limite de despesa definidos. O utilizador pode utilizar esta chave para aceder aos serviços de IA suportados, sem utilizar diretamente uma chave API permanentemente ligada à sua conta pessoal de pagamento.
No modelo Runtime-Key descrito nos materiais oficiais, o prompt do utilizador é enviado diretamente ao prestador de serviços de modelos de IA, em vez de ser encaminhado através do servidor de pagamentos zkAPI. O servidor de pagamentos verifica a elegibilidade para pagamento e trata da faturação, enquanto o prestador de serviços de IA trata da inferência do modelo. Após o fim da sessão, o sistema calcula a taxa efetiva com base nos registos de utilização assinados e deduz o montante correspondente do saldo privado do utilizador. O limite de despesa da chave temporária corresponde a um montante reservado e não significa que o utilizador vá necessariamente pagar a totalidade desse montante.
O zkAPI disponibiliza também um modo Proxy relativamente simples, no qual um servidor proxy encaminha os pedidos. Esta abordagem pode ser mais fácil de integrar, mas o servidor proxy pode aceder ao tráfego dos pedidos, o que cria um perímetro de privacidade diferente do modelo Runtime-Key. Por isso, ao analisar as capacidades de privacidade do zkAPI, é necessário distinguir os modos de funcionamento específicos, em vez de considerar que todos os métodos de implementação oferecem o mesmo nível de isolamento de dados.
O Vault é a infraestrutura de contratos inteligentes que o zkAPI utiliza para gerir os fundos dos utilizadores na Ethereum. Os utilizadores depositam ativos no Vault através de transações públicas on-chain e podem depois utilizar os seus saldos privados para pagar serviços de API de acordo com as regras do protocolo. Ao contrário da transferência direta de fundos para a conta de um prestador de serviços centralizado, as regras de gestão e levantamento dos fundos do Vault são implementadas através de contratos inteligentes. A conceção oficial permite aos utilizadores levantar os fundos restantes através do processo de saída on-chain correspondente, reduzindo a dependência da permanência de um único servidor de pagamentos online.
A Private Note representa o saldo privado que o utilizador pode controlar. Não é uma nova criptomoeda, mas uma credencial criptográfica utilizada para controlar e comprovar a elegibilidade para pagamento. Através da Note e da árvore de Merkle, os utilizadores podem provar que detêm um saldo válido sem divulgar os registos de financiamento correspondentes a cada pagamento. Isto significa que deixa de ser necessária uma relação direta de um para um entre o financiamento público on-chain e a utilização específica de serviços de IA.
O Nullifier impede o gasto duplo. Se um sistema de pagamentos privados ocultar as credenciais de saldo, mas não conseguir detetar a sua utilização repetida, um utilizador poderá gastar os mesmos fundos várias vezes. Por isso, o zkAPI utiliza Nullifiers para manter as verificações de unicidade necessárias, protegendo simultaneamente a privacidade das credenciais. Os três componentes tratam, respetivamente, da gestão de fundos, das provas privadas de elegibilidade para pagamento e da deteção de gasto duplo, formando em conjunto o mecanismo básico de pagamento do protocolo.
É importante salientar que o financiamento e os levantamentos do Vault continuam a ser transações públicas na Ethereum. O zkAPI oculta sobretudo a relação entre transações de financiamento específicas e a utilização posterior de API, em vez de tornar completamente invisíveis os endereços de financiamento, os montantes das transações ou toda a atividade on-chain.
As API de IA tradicionais utilizam geralmente saldos de conta ou faturação pós-paga. Depois de registarem uma conta, os programadores recebem uma chave API, e o sistema utiliza essa chave para identificar a origem dos pedidos, acompanhar a utilização de tokens e calcular as taxas. Este modelo oferece ferramentas de desenvolvimento, gestão de faturação e sistemas de apoio ao cliente maduros, mas os prestadores de serviços também podem associar os registos de utilização de API às informações das contas durante períodos prolongados.
O zkAPI utiliza credenciais de saldo privado e provas de conhecimento zero para verificar a elegibilidade para pagamento, procurando separar a identidade do utilizador, a origem do pagamento e os pedidos específicos. A sua principal diferença não é utilizar ou não ETH para pagamento, mas sim a possibilidade de o prestador do serviço estabelecer diretamente uma relação entre a conta de pagamento e os pedidos aos modelos.
| Dimensão de comparação | API de IA tradicional | zkAPI |
|---|---|---|
| Identidade de pagamento | Habitualmente ligada a uma conta registada | Utiliza credenciais privadas de pagamento |
| Autorização de API | Chave API de longo prazo ou token de conta | Prova de conhecimento zero e chave API temporária |
| Método de faturação | Saldo de conta ou faturação periódica | Crédito privado e registos de utilização efetiva |
| Associação de informações de pagamento | Os prestadores de serviços podem habitualmente associar contas e pedidos | Concebido para separar as origens dos pagamentos dos pedidos |
| Dependência da blockchain | Habitualmente desnecessária | Utiliza um contrato de financiamento na Ethereum |
| Privacidade do conteúdo dos pedidos | Geralmente visível para o prestador de serviços de modelos | Continua visível para o prestador de serviços de modelos |
| Principais limitações | Centralização dos dados das contas e associação à identidade | Custos das provas, complexidade do protocolo e limites de privacidade |
Assim, o zkAPI não pretende substituir completamente as chaves API tradicionais. Em vez disso, utiliza autorização temporária e credenciais privadas de pagamento para alterar a relação entre as chaves API e as identidades de pagamento de longo prazo. Para aplicações que apenas precisam de faturação e gestão de acesso convencionais, o modelo tradicional pode continuar a ser mais simples. Para utilizadores ou aplicações que pretendam reduzir a exposição das identidades de pagamento, o zkAPI oferece outra opção técnica.
O zkAPI pode reduzir a ligação direta entre as identidades de pagamento e os pedidos de API, mas não pode garantir conversas de IA completamente anónimas. A Ethereum Foundation afirmou claramente no seu anúncio oficial que os prestadores de serviços de IA continuam a poder ler os prompts enviados pelos utilizadores e as respostas geradas pelos modelos, porque a inferência dos modelos exige o processamento desse conteúdo. Por outras palavras, o zkAPI protege a privacidade da associação aos pagamentos; não fornece automaticamente inferência de IA com cifragem de ponta a ponta.
Os metadados de rede também representam um potencial risco para a privacidade. Se um utilizador aceder continuamente a um serviço a partir de um endereço IP fixo, o gateway de pagamentos ou o fornecedor do modelo poderá continuar a analisar o seu comportamento através dos horários de ligação, da frequência dos pedidos e de outras características da rede. Mesmo que não seja possível associar diretamente a credencial de pagamento, os padrões repetidos na camada de rede podem reduzir o anonimato. Por isso, os materiais oficiais tratam o anonimato de rede como uma questão que exige medidas técnicas adicionais, e não como uma capacidade que o zkAPI já assegura plenamente.
Além disso, os próprios prompts podem revelar a identidade. Por exemplo, se um utilizador fornecer repetidamente o mesmo contexto pessoal, nome de projeto empresarial ou conteúdo de conversas anteriores em diferentes sessões, o prestador de serviços de modelos poderá voltar a associar esses pedidos com base nas características do conteúdo. Mesmo sem um nome de conta, um estilo de escrita distintivo e informações contextuais contínuas podem fornecer indícios de identificação.
Assim, uma interpretação mais precisa é que o zkAPI pode reduzir a associação entre as identidades de pagamento e os registos de utilização de API ao nível da conceção do protocolo, mas uma proteção abrangente da privacidade na IA continua a exigir outras tecnologias, incluindo anonimato de rede, minimização de dados e computação com preservação da privacidade.
Os agentes de IA utilizam API de forma diferente dos utilizadores comuns em alguns aspetos. Os utilizadores tradicionais compram habitualmente subscrições de forma manual através de sites ou aplicações, enquanto os agentes de IA podem precisar de fazer chamadas automáticas a vários modelos, bases de dados ou serviços de computação em função de uma tarefa. Se cada serviço exigir uma conta, um método de pagamento e uma chave API de longo prazo distintos, a gestão de pagamentos e permissões pode tornar-se complexa para os sistemas automatizados.
Os mecanismos de crédito privado e autorização temporária disponibilizados pelo zkAPI oferecem uma abordagem técnica para serviços entre máquinas com pagamento por utilização. Um agente de IA pode obter acesso a API dentro de um montante de financiamento e de um limite de despesa predefinidos e, depois, fazer chamadas aos serviços relevantes de acordo com a tarefa concreta. Através de provas de conhecimento zero, o servidor de pagamentos pode verificar o crédito autorizado sem exigir que cada chamada esteja diretamente associada a uma conta de pagamento de longo prazo.
Além da inferência de modelos de IA, a Ethereum Foundation indicou consultas RPC de blockchain, geração de imagens e vídeos, serviços de largura de banda VPN e outras formas de faturação entre máquinas como potenciais casos de utilização. Estes serviços partilham características comuns: a faturação é habitualmente feita por chamada, tarefa de computação, tempo ou volume de tráfego, pelo que podem utilizar mecanismos semelhantes de autorização de crédito e liquidação com base em registos de utilização.
No entanto, os pagamentos automatizados por agentes de IA também exigem controlos rigorosos de fundos e permissões. Mesmo que a identidade de pagamento esteja protegida, configurações incorretas de tarefas, chamadas de API anómalas ou entradas maliciosas podem esgotar rapidamente os fundos. Por isso, as implementações reais precisam de definir limites por chamada, orçamentos de sessão, listas de serviços permitidos e monitorização de utilizações anómalas. Os pagamentos privados não devem ser equiparados à segurança dos pagamentos automatizados.
A primeira categoria de desafios decorre das provas criptográficas e da complexidade do sistema. Embora as provas de conhecimento zero possam ocultar algumas informações subjacentes, a geração e a verificação de provas, bem como a gestão de credenciais, aumentam os custos de desenvolvimento e operação. O protocolo tem de assegurar a atualização correta dos saldos privados dos utilizadores e impedir o gasto duplo, tratando simultaneamente da caducidade de chaves temporárias, da liquidação com base em registos de utilização, de saídas anómalas e de outras situações. Em comparação com uma base de dados tradicional de faturação centralizada, esta conceção exige que mais componentes criptográficos e de contratos inteligentes funcionem em conjunto.
A segunda categoria diz respeito à segurança dos contratos inteligentes e dos serviços de pagamento. O contrato Vault gere fundos on-chain. Se existirem vulnerabilidades no contrato, na lógica de verificação de provas ou na implementação do cliente, a segurança dos fundos dos utilizadores poderá ser afetada. Embora o projeto oficial tenha publicado o seu código-fonte e implementado componentes relacionados na rede principal da Ethereum, o seu repositório no GitHub continua a classificar o protocolo como uma implementação experimental. Isto significa que os utilizadores e os programadores não devem presumir que o protocolo dispõe de todas as proteções de segurança de um sistema comercial de pagamentos maduro apenas por estar operacional na rede principal.
A terceira categoria é o equilíbrio entre a proteção da privacidade e o funcionamento real dos serviços. Os prestadores de serviços de IA continuam a precisar de identificar abusos, aplicar limites à frequência dos pedidos e tratar de litígios de faturação, enquanto os mecanismos de pagamento anónimo podem dificultar a aplicação direta dos controlos de risco tradicionais baseados em contas. O zkAPI mantém as restrições de faturação necessárias através de chaves temporárias, limites de despesa e registos de utilização assinados, mas os prestadores de serviços continuam a precisar de desenvolver mecanismos de prevenção de abusos adequados a ambientes de pagamentos privados.
Além disso, o protocolo não resolve automaticamente o anonimato de rede nem a fuga de informação contida nos prompts. Nas aplicações de IA que processam informações altamente sensíveis, a utilização exclusiva do zkAPI não basta para assegurar uma confidencialidade abrangente dos dados. É também necessário avaliar as políticas de tratamento de dados do fornecedor do modelo, os métodos de ligação à rede e tecnologias adicionais de computação com preservação da privacidade.
O lançamento do zkAPI reflete a expansão da exploração de aplicações de IA pela Ethereum, dos pagamentos de ativos para a autorização com privacidade e a faturação de serviços. Os pagamentos tradicionais em blockchain centram-se geralmente na capacidade de transferir ativos entre diferentes endereços. O zkAPI vai mais longe, ao analisar como concluir pagamentos reduzindo a ligação informacional entre as identidades de pagamento e a utilização efetiva dos serviços. Isto significa que os contratos inteligentes da Ethereum podem servir não só como infraestrutura de transferência de pagamentos, mas também como parte do controlo de acesso e da gestão de fundos para serviços digitais.
Na perspetiva da arquitetura técnica, o zkAPI combina gestão de fundos on-chain com autorização de API off-chain. A Ethereum trata do contrato de fundos e da lógica de verificação necessária, as provas de conhecimento zero ocultam a ligação entre as credenciais de pagamento e os comportamentos específicos de utilização, e os prestadores de serviços de IA continuam a realizar a inferência dos modelos. Esta divisão evita colocar diretamente cada chamada de API na blockchain e fornece uma conceção de referência para futuros serviços com pagamento por utilização.
No entanto, o zkAPI continua nas fases iniciais de adoção real. O seu desenvolvimento a longo prazo vai depender não só da maturidade da tecnologia de provas de conhecimento zero, mas também da disponibilidade dos prestadores de serviços de IA para o integrar, da facilidade de integração para os programadores e da necessidade efetiva dos utilizadores de separar as identidades de pagamento dos registos de utilização dos modelos. Para a Ethereum, a importância principal do zkAPI reside na demonstração de uma arquitetura operacional de pagamentos privados — e não na ideia de que todos os serviços de API de IA vão passar a utilizar pagamentos on-chain.
zkAPI é um protocolo de pagamento de API centrado na privacidade, lançado através de uma colaboração entre a Ethereum Foundation e o Open Anonymity Project. Através de contratos inteligentes Vault, Private Notes, provas de conhecimento zero e chaves API temporárias, separa as identidades de pagamento dos utilizadores dos seus registos de utilização de serviços de IA. Os utilizadores podem depositar fundos antecipadamente na Ethereum e, depois, obter acesso a API através de provas criptográficas, sem divulgar a origem do financiamento correspondente a cada pedido.
Em comparação com os métodos tradicionais de pagamento de API de IA, a inovação central do zkAPI não consiste simplesmente em utilizar ETH ou stablecoins para adquirir serviços de modelos. Em vez disso, procura resolver a associação de longo prazo entre contas de pagamento e conteúdo dos pedidos. Ao combinar a gestão de fundos on-chain com a faturação da utilização off-chain, o protocolo pode manter a verificação de quotas e a deteção de gasto duplo, melhorando simultaneamente a proteção da privacidade na camada de pagamento.
No entanto, o zkAPI não significa que os serviços de IA se tornem completamente anónimos. Os fornecedores de modelos podem continuar a ler os prompts, enquanto os metadados de rede e as características do conteúdo também podem revelar informações dos utilizadores. A aplicação generalizada deste tipo de tecnologia a agentes de IA, à inferência de modelos e a outros serviços com pagamento por utilização exige ainda uma validação adicional da sua segurança, escalabilidade e viabilidade comercial.
zkAPI é um protocolo de pagamento de API centrado na privacidade e baseado em provas de conhecimento zero. Permite aos utilizadores comprovar que dispõem de crédito suficiente para utilizar serviços através de credenciais privadas de pagamento, sem divulgar ao servidor de pagamentos a origem específica do financiamento ou a identidade de pagamento de longo prazo.
O zkAPI foi desenvolvido em conjunto pelo Open Anonymity Project e pela Ethereum Foundation, e a sua entrada em funcionamento na rede principal da Ethereum foi anunciada em 1 de outubro de 2026. É uma implementação técnica experimental desenvolvida através dessa colaboração e não um protocolo obrigatório da camada base da rede Ethereum.
Os materiais oficiais da Ethereum Foundation indicam que ativos como ETH e USDC podem ser utilizados em cenários de financiamento e pagamento relacionados. No entanto, os ativos específicos suportados pelo cliente, pelo contrato Vault e pela versão implementada devem ser confirmados na documentação mais recente da implementação relevante.
Não. O zkAPI oculta sobretudo a relação entre as identidades de pagamento e os registos de utilização de API. Os prestadores de serviços de modelos de IA continuam a precisar de ler os prompts para gerar respostas, pelo que o conteúdo dos prompts não é automaticamente cifrado apenas por ser utilizado o zkAPI.
Os Nullifiers são utilizados para detetar se as credenciais de saldo privado foram gastas mais do que uma vez. O sistema pode impedir a reutilização do mesmo crédito através da verificação de identificadores únicos, evitando simultaneamente a divulgação direta da totalidade das informações secretas das credenciais.
O zkAPI pode fornecer aos agentes de IA faturação por utilização, autorização temporária e credenciais privadas de pagamento. No entanto, as implementações reais continuam a precisar de limites orçamentais, permissões de acesso e controlos de utilizações anómalas para reduzir os riscos financeiros associados às chamadas automatizadas.
* As informações não se destinam a ser e não constituem aconselhamento financeiro ou qualquer outra recomendação de qualquer tipo oferecido ou endossado pela Gate.
* Este artigo não pode ser reproduzido, transmitido ou copiado sem fazer referência à Gate. A violação é uma violação da Lei de Direitos de Autor e pode estar sujeita a ações legais.





