O que acontece quando você liga um assistente de IA ao seu sistema de gestão, quem autoriza o quê, por quanto tempo vale a permissão, e os dois pontos da lei brasileira que quase todo mundo repete errado.
Sim, a IA pode mexer no seu sistema. Mas só no que você autorizar, só com o seu login, e só até onde o seu próprio perfil de usuário já ia. O que decide o risco não é a tecnologia: é a permissão que você concede e, principalmente, se alguém volta a revisar essa permissão depois.
Desde que assistentes como o Claude e o ChatGPT passaram a se conectar a sistemas de verdade, essa virou a pergunta mais frequente de quem usa PDV e ERP. Ela é legítima, e a resposta boa não é “é seguro, confia”. A resposta boa é saber exatamente o que o assistente lê, o que ele escreve, o que ele faz sem perguntar e como você corta o acesso quando quiser.
Abaixo você encontra a diferença entre ler e executar, quem de fato exibe a tela de “permitir?”, o que o padrão técnico exige e o que ele apenas recomenda, o caso real em que uma autorização já concedida virou brecha, o que a legislação brasileira realmente obriga, e sete perguntas para levar ao seu fornecedor.
O que muda quando a IA conversa com o sistema
Até pouco tempo atrás, usar IA com os dados do seu negócio significava copiar um relatório e colar no chat. O assistente não via o seu sistema, e você fazia a ponte na mão.
O que mudou foi o surgimento de um padrão para essa ponte. Ele se chama Model Context Protocol, ou MCP, e foi lançado pela Anthropic em 25 de novembro de 2024 como padrão aberto. Em 9 de dezembro de 2025, a Anthropic doou o protocolo para a Agentic AI Foundation, um fundo dirigido sob a Linux Foundation, cofundado por Anthropic, Block e OpenAI. A versão vigente da especificação é a de 28 de julho de 2026.
Na prática, o MCP é a tomada padronizada. Antes, cada sistema precisava de uma integração feita sob medida para cada assistente. Com o padrão, o sistema publica uma vez o que sabe fazer, e qualquer assistente compatível descobre e usa. É padronização, não mágica: a comparação honesta é com a tomada universal, não com uma nova forma de inteligência.
Por que isso importa para você, e não só para o seu time de TI: a partir do momento em que existe uma tomada padrão, a pergunta deixa de ser técnica e passa a ser de gestão. Não é mais “dá para integrar?”. É “quem eu deixo plugar, no que, e por quanto tempo?”. Essa é uma decisão sua, não do fornecedor.
Ler, pedir e executar
A especificação separa o que uma IA faz no seu sistema em três coisas, e confundir as três é a origem de quase todo o medo mal direcionado. Nas palavras da própria especificação, em tradução livre:
| Nome na especificação | O que é | Exemplo no seu negócio | Muda dado seu? |
|---|---|---|---|
| Resources | “Contexto e dados, para o usuário ou para o modelo de IA usar”. É o que a IA pode ler. | O relatório de venda de ontem, a lista de produtos, o saldo de estoque | Não |
| Prompts | “Mensagens e fluxos prontos, em modelo, para os usuários”. São roteiros que você escolhe. | “Me dê o resumo de fechamento do dia” | Não |
| Tools | “Funções para o modelo de IA executar”. | Cadastrar um produto, alterar um preço, dar baixa em estoque | Sim |
Só a terceira linha mexe em dado seu. Quando alguém pergunta “a IA vai poder mexer no meu sistema?”, a pergunta real é sobre Tools. E a boa notícia é que a permissão de ler e a permissão de executar são concedidas separadamente, em qualquer implementação séria.
Quem é que te pergunta “posso?”
Esse é o ponto que mais gera confusão, e vale guardar: quem pede a sua autorização não é o seu sistema de gestão, é o aplicativo de IA que você instalou.
A especificação chama o aplicativo de IA de host, e é dele o papel de obter o consentimento e de exibir a tela de permissão. O seu sistema de gestão é o server, a ponta que oferece os dados e as ações. Entre os dois fica o client, o conector dentro do aplicativo.
A consequência prática é desconfortável e precisa ser dita: se você instalar um aplicativo de IA desconhecido e der a ele acesso amplo, o seu sistema de gestão não tem como adivinhar que aquilo foi um erro. É por isso que fornecedores de plataforma passaram a tratar esse consentimento como item de segurança, e não de usabilidade.
A Microsoft, ao anunciar suporte nativo a MCP no Windows 11 em 19 de maio de 2025, resumiu o princípio assim: “o usuário está no controle de todas as operações sensíveis de segurança feitas em seu nome”. E detalhou o modelo: “os usuários devem aprovar explicitamente cada par cliente-ferramenta, com suporte a granularidade por recurso”. O Google, ao anunciar servidores MCP gerenciados para seus serviços em 10 de dezembro de 2025, foi na mesma direção, oferecendo controle de acesso por IAM e registro de auditoria.
O que o padrão exige e o que só recomenda
Aqui está a informação mais importante deste artigo, e a que praticamente nenhum conteúdo em português apresenta corretamente.
A especificação do MCP recomenda com força que exista sempre uma pessoa capaz de negar a execução de uma ação. O texto, na página de ferramentas, traz um aviso destacado: “para confiança, segurança e proteção, deveria sempre haver um humano no circuito, com a capacidade de negar invocações de ferramenta”.
Mas ela não exige isso, e admite o motivo com todas as letras: “o MCP, por si, não consegue impor esses princípios de segurança no nível do protocolo”. A autorização, inclusive, é descrita como item opcional da implementação.
Traduzindo: o padrão descreve o comportamento correto e entrega a responsabilidade de garanti-lo a quem constrói o aplicativo e a quem constrói o sistema. Ou seja, o seu nível de proteção não vem do padrão, vem do seu fornecedor. Duas empresas podem seguir a mesma especificação e oferecer níveis de risco completamente diferentes. É exatamente isso que o checklist mais adiante serve para descobrir.
O que a especificação faz bem é o controle de entrada. Ela se apoia em OAuth 2.1, o mesmo tipo de login de “entrar com o Google”, e trabalha com escopos, que são permissões fatiadas. A regra escrita é a do menor privilégio: os clientes “deveriam seguir o princípio do menor privilégio, requisitando apenas os escopos necessários para as operações pretendidas”. Há até um fluxo formal de elevação gradual: se a IA tenta uma ação de escrita tendo só permissão de leitura, o sistema devolve um erro de escopo insuficiente e o aplicativo precisa pedir a permissão maior.
A etiqueta não é cadeado
A especificação prevê etiquetas para marcar o comportamento de cada ferramenta. Nos campos do schema oficial, uma ferramenta pode se declarar como readOnlyHint, isto é, “não modifica o ambiente”, ou como destructiveHint, “pode fazer atualizações destrutivas no ambiente”.
Parece resolver o problema. Não resolve, e o próprio padrão avisa. O schema diz, em nota destacada: “todas as propriedades em ToolAnnotations são dicas. Não há garantia de que ofereçam uma descrição fiel do comportamento da ferramenta”. E completa: “os clientes nunca deveriam tomar decisões de uso de ferramenta com base em ToolAnnotations recebidas de servidores não confiáveis”.
Há um detalhe revelador nos valores padrão desses campos. readOnlyHint tem padrão falso, e destructiveHint tem padrão verdadeiro. Ou seja: na ausência de declaração, o padrão presume que a ferramenta escreve e pode destruir. É pessimismo por projeto, e é a postura correta.
A lição para você é curta: etiqueta não é cadeado. O cadeado é a permissão que você concedeu, e a conferência que alguém faz depois.
Seis controles para comparar fornecedores
Lendo a documentação pública de fornecedores que já oferecem conexão de IA aos seus sistemas, as posturas variam bastante dentro do mesmo padrão técnico. Para dar um exemplo sem entrar em comparação de marcas: em um ERP brasileiro de pequenas e médias empresas, a documentação informa que ações de incluir, alterar e faturar acontecem na hora, e que nas configurações do conector o próprio usuário pode escolher o que a IA faz sem perguntar. Em uma plataforma internacional de PDV e pagamentos, a documentação oferece uma variável de configuração que restringe a conexão a operações somente de leitura, além de escopos granulares e uma lista de aplicativos aprovados.
Nenhuma das duas está errada. São escolhas de projeto diferentes, e quem assume o risco é quem configura. O que interessa é você saber o que perguntar. Estes são os seis controles que de fato mudam o seu risco.
| Controle | O que verificar | Por que importa |
|---|---|---|
| Identidade | A conexão usa o seu login do sistema, ou uma chave de API avulsa? | Com o seu login, a IA herda o seu perfil e não pode mais do que você. Com chave avulsa, a permissão vira um objeto solto que alguém pode copiar. |
| Escopo | Dá para liberar só leitura, sem liberar escrita? | É o controle mais eficaz e o mais barato. A maior parte do valor de uma IA de gestão está em ler e resumir, não em alterar. |
| Aprovação | O que ela faz sem perguntar? Existe pré-visualização antes de gravar? Quem pode desligar essa pergunta? | É aqui que as implementações mais divergem. Se a aprovação é opcional, o risco passa a depender de quem configurou. |
| Prazo | A autorização vence? Em quanto tempo? | Permissão sem prazo é permissão esquecida. Veja a próxima seção. |
| Revogação | Você consegue ver os aplicativos conectados e cortar o acesso sozinho, na hora? | Sem isso, revogar depende de abrir ticket com o fornecedor. |
| Destino do dado | Para qual provedor de IA os dados consultados vão? Isso está escrito em algum lugar? | Essa informação define a sua cadeia de responsabilidade na LGPD, como você vê mais adiante. |
A permissão concedida e nunca revista
Existem falhas de segurança reais e catalogadas ligadas a MCP. É importante dizer com precisão o que elas são e o que não são.
Elas não são falhas de PDV nem de ERP. As que estão registradas em base pública são de ferramentas de desenvolvedor. Duas delas, a CVE-2025-54135 e a CVE-2025-54136, são do Cursor, um editor de código. Outras duas, a CVE-2026-12957 e a CVE-2026-12958, são de componentes de desenvolvimento da AWS. Todas exigem que a vítima abra um projeto de programação em um editor. Nenhuma afeta frente de caixa, estoque ou emissão fiscal. Qualquer texto que sugira o contrário está errado.
O que elas provam, porém, vale para qualquer sistema, e é o motivo de estarem aqui. Veja a descrição oficial da CVE-2025-54136, publicada em 1 de agosto de 2025: “atacantes podem conseguir execução de código remota e persistente modificando um arquivo de configuração MCP que já era confiável”.
Leia a parte em destaque de novo. O ataque não quebrou o protocolo nem adivinhou senha. Ele se aproveitou de uma autorização que já havia sido dada e nunca mais foi revista. A aprovação continuou valendo depois que o conteúdo por trás dela mudou.
É isso que você deve procurar no seu fornecedor. O risco prático não é “a IA invadir o seu sistema”. É uma permissão concedida uma vez, numa tarde corrida, e que segue ativa um ano depois, possivelmente de um funcionário que já saiu. Daí a pergunta mais útil de todo este artigo: o que o meu sistema faz quando a configuração muda ou quando o tempo passa? Pergunta de novo, ou continua valendo o “sim” de antes?
Note que as duas pontuações de gravidade dessas falhas divergem entre as fontes: a CVE-2025-54136 recebeu 8,8 do NIST e 7,2 da entidade que atribuiu o registro. Não existe número único de consenso, e isso também é parte da leitura honesta.
O que a lei brasileira realmente exige
Aqui a conversa muda de assunto, porque a maior parte do que circula sobre LGPD e IA no Brasil está desatualizada ou simplesmente errada. Dois pontos em especial.
O artigo 20 e o mito da revisão humana
Você provavelmente já leu que a LGPD obriga revisão humana de decisão automatizada. Não obriga.
O artigo 20 da LGPD garante ao titular “o direito a solicitar a revisão de decisões tomadas unicamente com base em tratamento automatizado de dados pessoais que afetem seus interesses”. A redação original, de 2018, dizia “solicitar revisão, por pessoa natural, de decisões”. Essa expressão foi retirada pela Lei 13.853, de 2019.
E não foi acidente. A mesma lei acrescentaria um parágrafo determinando que a revisão “deverá ser realizada por pessoa natural”, e esse parágrafo foi vetado. A razão oficial do veto, na Mensagem de Veto nº 288, de 8 de julho de 2019, é explícita: a exigência “contraria o interesse público, tendo em vista que tal exigência inviabilizará os modelos atuais de planos de negócios de muitas empresas, notadamente das startups”.
O que continua valendo, e é relevante, é o direito do cliente a “informações claras e adequadas a respeito dos critérios e dos procedimentos utilizados para a decisão automatizada, observados os segredos comercial e industrial”.
Importante, e é inferência nossa, não texto de lei: se um agente de IA que consulta relatório ou cadastra produto se enquadra como “decisão automatizada” do artigo 20 é assunto em aberto. A própria ANPD, ao consolidar a tomada de subsídios sobre o tema, registrou divergência sobre quais decisões se enquadram. E não existe norma da ANPD regulamentando o artigo 20: no balanço da agenda regulatória com dados até 30 de junho de 2026, o status é de minuta em elaboração na área técnica.
Preciso avisar que é um robô?
Pela lei em vigor hoje, não. Nenhuma norma brasileira vigente obriga informar ao consumidor que ele está falando com um sistema automatizado. O Código de Defesa do Consumidor não menciona atendimento automatizado, robô, chatbot ou inteligência artificial. O que existe é o dever geral de informação clara e precisa.
E o decreto do SAC, que muita gente cita, não alcança restaurante, bar, padaria, lanchonete nem varejo comum. O Decreto 11.034, de 2022, limita-se ao atendimento “no âmbito dos fornecedores dos serviços regulados pelo Poder Executivo federal”.
Houve novidade recente, e ela não muda essa conclusão. O Decreto 13.135, de 9 de outubro de 2026, publicado no Diário Oficial de 13 de outubro de 2026, revoga o decreto anterior e entra em vigor vinte dias após a publicação, o que pela contagem cai no início de novembro de 2026 (cálculo nosso). Ele também delimita o alcance a fornecedores de produtos e serviços regulados pelo Executivo federal e a serviços financeiros supervisionados pelo Banco Central. Restaurante e loja seguem fora.
O que o novo decreto faz, e vale conhecer, é permitir expressamente a IA no atendimento, exigindo em troca a saída humana. O artigo 3º, parágrafo 3º: “o fornecedor poderá adotar procedimentos automatizados, inclusive sistemas de inteligência artificial, para a triagem, a distribuição interna e a resolução das demandas, desde que assegurada ao consumidor a opção de atendimento em tempo real por pessoa humana”.
Recomendação: mesmo sem obrigação legal, avisar que o atendimento é automatizado e oferecer caminho para uma pessoa é a prática que o dever de informação do CDC já aponta, é o que o decreto novo exige de quem ele alcança, e é para onde os projetos de lei em tramitação caminham. Avisar custa uma linha e evita atrito.
De quem é a responsabilidade quando o software é de terceiro
Na estrutura da LGPD, quem define as finalidades do tratamento é o controlador, e quem trata os dados em nome dele é o operador. Em geral, numa relação entre empresa e fornecedor de software, a empresa contratante é a controladora e o fornecedor é o operador, conforme o guia orientativo da ANPD sobre agentes de tratamento. Quem o fornecedor subcontrata vira suboperador. Essa aplicação ao seu caso é inferência: o enquadramento real depende do contrato e de quem de fato decide as finalidades.
O que é texto de lei, e importa: pelo artigo 42, parágrafo 1º, inciso I, “o operador responde solidariamente pelos danos causados pelo tratamento quando descumprir as obrigações da legislação de proteção de dados ou quando não tiver seguido as instruções lícitas do controlador”.
Por isso o item “destino do dado” está no checklist. Quando você conecta um assistente, os dados consultados passam pelo provedor de IA daquele aplicativo. Saber qual é, e que isso está documentado, é o que te permite montar a sua cadeia de responsabilidade em vez de descobrir depois.
O marco legal da IA ainda é projeto
Não existe lei de marco legal da inteligência artificial sancionada no Brasil. O PL 2338/2023 foi aprovado pelo Senado e está na Câmara dos Deputados desde 17 de março de 2025, aguardando parecer do relator em comissão especial, com movimentação registrada em 2 de setembro de 2026. Há ainda outro projeto, específico sobre consumidor e IA, aprovado em comissão em 23 de junho de 2026, que obrigaria informar de forma clara a interação com sistemas de IA. Nenhum dos dois é lei. Não monte a sua operação pressupondo obrigação que ainda não existe, e desconfie de quem vender adequação a uma norma que não foi publicada.
Sobre voz, uma correção que vale fazer: a palavra “voz” não aparece na definição de dado sensível da LGPD. O artigo 5º, inciso II, cita dado biométrico “quando vinculado a uma pessoa natural”. A ANPD, em um radar tecnológico de junho de 2024, lista a voz entre as características biométricas, mas aquele documento é estudo preliminar, não norma. Logo: afirmar que gravar a voz de um cliente é automaticamente tratamento de dado sensível não se sustenta no texto da lei. A leitura razoável, e ela é inferência, é distinguir transcrever o que a pessoa disse de identificar a pessoa pelo timbre da voz. Antes de montar operação com voz, consulte o seu jurídico.
Este artigo é levantamento de fontes oficiais, não parecer jurídico. Para o seu caso concreto, fale com um advogado.
As sete perguntas para fazer ao seu fornecedor
- A conexão usa o meu login do sistema, ou preciso gerar uma chave de API que fica guardada em algum lugar?
- O assistente consegue fazer mais do que o meu próprio perfil de usuário já permite?
- Consigo liberar somente leitura, sem liberar nenhuma alteração?
- Quais ações ele executa sem me perguntar, e quem na minha empresa pode desligar essa pergunta?
- A autorização que eu dou tem prazo de validade? Qual?
- Onde eu vejo os aplicativos conectados e como eu corto o acesso sozinho, sem abrir ticket?
- Para qual provedor de IA vão os dados que o assistente consulta, e isso está escrito na documentação?
Como isso funciona no NoxMob
Para não deixar as sete perguntas no abstrato, aqui está como o NoxMob responde cada uma. Tudo abaixo está na documentação oficial do sistema.
O NoxMob tem um conector MCP que liga o sistema a assistentes de IA, entre eles Claude, ChatGPT, Claude Code, Cursor e VS Code. Não existe chave de API nem token para copiar: o login é feito com o mesmo CNPJ, usuário e senha do NoxMob, na tela que o próprio aplicativo abre. E a regra de base é a que você quer ouvir: cada pessoa conecta com o próprio login, escolhe o que o aplicativo pode acessar, e o aplicativo nunca passa dos direitos dessa pessoa no NoxMob.
As permissões são cinco, e elas têm hierarquia:
| Permissão | O que libera | Depende de |
|---|---|---|
| Base de conhecimento | Consultar a documentação oficial do sistema | Nada. É a única autônoma |
| Relatórios | Executar relatórios por categoria, nas lojas autorizadas | Funcionalidade contratual de agentes de IA |
| Análise de dados | Receber resumos calculados, com totais, rankings e tendências | Relatórios |
| Cadastros | Consultar produtos e registros da loja, como clientes, fornecedores e unidades | Funcionalidade contratual de agentes de IA |
| Alterar cadastros | Criar e modificar produtos e cadastros, com pré-visualização e aprovação obrigatória | Cadastros |
Três detalhes dessa tabela merecem destaque, porque respondem direto ao que vimos nas seções anteriores.
Primeiro: a única permissão que escreve exige pré-visualização e aprovação obrigatória. Lembre que a especificação do MCP apenas recomenda o humano no circuito e admite não conseguir impor. Aqui a aprovação é condição da própria permissão, e não uma preferência que se desliga.
Segundo: sem a funcionalidade contratual de agentes de IA, a conexão fica restrita à base de conhecimento. O comportamento de fábrica é consultar documentação, não acessar dado de loja.
Terceiro: a autorização concedida tem validade de 30 dias a partir do login. É a resposta estrutural ao problema da seção anterior, aquela permissão dada uma vez e nunca mais revista. Aqui ela expira sozinha.
Além disso, a tela do conector tem o bloco de conexões, onde a pessoa vê os aplicativos conectados ao seu CNPJ e usuário e pode revogar uma conexão ou todas. Quem tem o direito de configurar direitos de funcionários enxerga também a política e as conexões da empresa. E a documentação informa expressamente que os dados consultados são encaminhados ao provedor de IA do aplicativo usado, dando como exemplo Anthropic ou OpenAI, que é a informação de que você precisa para montar a cadeia de responsabilidade da seção anterior.
O conector herda o controle de acesso que já existe no sistema: os direitos por grupo de usuários, com estados liberado, bloqueado e validar no grupo, e a regra de que bloqueado vence liberado. Se um funcionário não vê uma tela, o assistente dele também não vê.
Para quem quer apenas ler e entender os números, sem liberar nada que altere, o caminho é a IA integrada ao sistema e o conjunto de agentes de IA do sistema para restaurante, que trabalham sobre os indicadores de desempenho que o sistema já calcula. Do lado de alterar dado, o uso mais maduro hoje é o cadastro de produtos com inteligência artificial, justamente porque é a operação em que a pré-visualização antes de gravar faz mais diferença.
Em desenvolvimento, ainda sem data de lançamento e ainda não disponível: conversar com a IA do NoxMob por voz dentro do próprio sistema, perguntando falando e ouvindo a resposta com o dado na hora, e também enviar um áudio no chat e receber a resposta em áudio, inclusive no aplicativo do gestor no celular.
Quer ver o conector e as permissões funcionando antes de decidir?
Em uma demonstração do NoxMob a gente abre a tela do conector, mostra as cinco permissões, a pré-visualização antes de gravar e onde você revoga o acesso. Você faz as sete perguntas deste artigo e vê a resposta na tela.
Perguntas frequentes
A IA consegue alterar preço ou estoque sozinha?
Depende inteiramente do que você autorizou e de como o seu fornecedor implementou. Tecnicamente, uma ferramenta de escrita pode alterar dado sem perguntar, porque o padrão MCP recomenda mas não impõe aprovação humana. No NoxMob, a permissão que cria e modifica cadastros é separada da de consulta, depende dela, e tem pré-visualização e aprovação obrigatória. Se você não liberar essa permissão, nada é alterado.
Preciso dar minha senha para a IA?
Não deveria. O padrão usa OAuth, o mesmo mecanismo de “entrar com o Google”: você se autentica na tela do seu próprio sistema e o aplicativo recebe uma autorização, não a sua senha. No conector do NoxMob não existe chave de API nem token para copiar, e o login é feito com o CNPJ, usuário e senha na tela que o próprio aplicativo abre. Se algum fornecedor pedir que você cole a senha dentro do chat, isso é motivo para parar.
Por quanto tempo vale a permissão que eu dei?
Essa é a pergunta que quase ninguém faz e que mais importa. A especificação do MCP não impõe prazo de validade para a autorização, então isso é decisão de cada fornecedor. No NoxMob, a autorização do conector tem validade de 30 dias a partir do login. Pergunte esse número ao seu fornecedor: permissão sem prazo é permissão esquecida.
Como eu revogo o acesso de um assistente?
Procure, no seu sistema, uma tela que liste os aplicativos conectados. No NoxMob, o conector tem o bloco de conexões, onde você vê os aplicativos ligados ao seu CNPJ e usuário e pode revogar uma conexão específica ou todas. Quem administra direitos de funcionários vê também as conexões da empresa. Se a revogação depender de abrir ticket com o fornecedor, considere isso um ponto negativo.
Meus dados vão para a OpenAI ou para a Anthropic?
Quando você usa um assistente de IA conectado ao seu sistema, os dados consultados passam pelo provedor daquele assistente. A documentação do conector do NoxMob informa isso expressamente, citando como exemplo Anthropic e OpenAI. Essa informação não é detalhe técnico: ela define a sua cadeia de responsabilidade na LGPD, porque o provedor entra como mais um elo no tratamento. Exija que esteja documentado por escrito.
Sou obrigado a avisar meu cliente que ele está falando com um robô?
Pela lei em vigor hoje, não. Nenhuma norma brasileira vigente obriga esse aviso, e o decreto do SAC não alcança restaurante, bar, padaria nem varejo comum, nem na versão de 2022 nem no Decreto 13.135, de outubro de 2026. Mas o novo decreto, para quem ele alcança, permite IA no atendimento exigindo a opção de atendimento humano. Avisar e oferecer saída para uma pessoa é a prática recomendável, e é o caminho dos projetos de lei em tramitação.
Se a IA errar, de quem é a responsabilidade?
Na LGPD, em regra a empresa que define as finalidades do tratamento é a controladora e responde por ele, e o fornecedor de software é operador. Mas o artigo 42, parágrafo 1º, inciso I, prevê que o operador responde solidariamente quando descumpre a legislação de proteção de dados ou quando não segue as instruções lícitas do controlador. Em termos práticos: coloque no contrato o que o fornecedor pode e não pode fazer com os dados, e guarde registro do que foi autorizado. Isso não é parecer jurídico.
A lei brasileira já exige revisão humana de decisão automatizada?
Não. O artigo 20 da LGPD garante o direito de solicitar revisão de decisão tomada unicamente por tratamento automatizado, e o direito a informação clara sobre os critérios usados. A expressão “por pessoa natural” existia na redação de 2018 e foi retirada pela Lei 13.853, de 2019, e o parágrafo que exigiria revisão por pessoa natural foi vetado, pela Mensagem de Veto nº 288, de 8 de julho de 2019. A ANPD ainda não publicou norma regulamentando o artigo 20.
O que fazer a partir daqui
Se você está avaliando conectar uma IA ao seu sistema, não comece pela pergunta “é seguro?”. Ela não tem resposta útil. Comece liberando apenas leitura, para uma pessoa só, e veja o que a IA entrega com relatório e análise antes de liberar qualquer coisa que altere dado. A maior parte do valor está nessa primeira metade.
Depois, leve as sete perguntas deste artigo ao seu fornecedor e anote as respostas. As duas que mais separam uma implementação madura de uma improvisada são o prazo de validade da autorização e quem pode desligar a aprovação antes de gravar.
E marque na agenda uma revisão trimestral das conexões ativas. O caso catalogado que mais ensina sobre esse assunto não envolveu senha quebrada nem protocolo furado: envolveu uma permissão que já era confiável e que ninguém mais olhou.
Fontes consultadas
- Anthropic: anúncio original do Model Context Protocol como padrão aberto, com os autores do projeto (25/11/2024).
- Anthropic e Linux Foundation: doação do MCP para a Agentic AI Foundation, fundo dirigido sob a Linux Foundation, cofundado por Anthropic, Block e OpenAI (09/12/2025).
- Especificação do MCP, versão 2026-07-28: seções de arquitetura, de segurança e confiança, de ferramentas e de autorização. É a fonte das citações sobre o protocolo não conseguir impor os princípios de segurança, sobre o humano no circuito, sobre a autorização ser opcional e sobre o menor privilégio.
- Schema oficial do MCP: definição dos campos
readOnlyHintedestructiveHint, seus valores padrão e a nota de que as anotações são apenas dicas e não garantem descrição fiel do comportamento da ferramenta. - Microsoft: anúncio do suporte a MCP no Windows 11, com o princípio de que o usuário está no controle das operações sensíveis e a exigência de aprovação explícita por par cliente-ferramenta (19/05/2025).
- Google Cloud: anúncio de servidores MCP gerenciados para serviços Google, com controle de acesso por IAM e registro de auditoria (10/12/2025).
- NVD, CVE-2025-54136 e CVE-2025-54135: falhas no editor de código Cursor, com as descrições oficiais e as pontuações divergentes entre o NIST e a entidade que atribuiu o registro (publicadas em 01/08/2025 e 04/08/2025). Ambas são de ferramenta de desenvolvedor, não de sistema de gestão.
- Planalto, Lei 13.709/2018 (LGPD): artigos 5º, 7º, 11, 20, 37, 42, 46 e 48, na redação vigente.
- Planalto, Mensagem de Veto nº 288: veto ao parágrafo que exigiria revisão de decisão automatizada por pessoa natural, com a razão oficial do veto (08/07/2019).
- Planalto, Decreto 11.034/2022 e Decreto 13.135/2026: o escopo do SAC em ambos os decretos, a revogação do anterior e a autorização expressa de uso de inteligência artificial no atendimento com opção de atendimento humano (09/10/2026, publicado no DOU de 13/10/2026).
- Planalto, Lei 8.078/1990 (CDC): dever de informação adequada e clara, artigos 4º, 6º e 31.
- ANPD: guia orientativo sobre definições dos agentes de tratamento, com a distinção entre controlador, operador e suboperador (versão 2.0, abril de 2022 na capa do documento).
- ANPD: balanço da agenda regulatória 2025-2026, com o status de minuta em elaboração para a regulamentação do artigo 20 e para dados biométricos (dados até 30/06/2026).
- Câmara dos Deputados: ficha de tramitação do PL 2338/2023, na Câmara desde 17/03/2025, aguardando parecer do relator em comissão especial (consultado em 26/10/2026).
- Documentação oficial do NoxMob: conector MCP, permissões de acesso para aplicativos de IA, validade da autorização e controle de direitos por grupo de usuários (documento atualizado em 15/10/2026).
