> ## Content Index > Fetch the complete content index at: https://ibsonmachado.me/llms.txt > Use this file to discover other available public pages before exploring further. # A parte da IA agêntica que sua empresa não deveria terceirizar - URL: https://ibsonmachado.me/a-parte-da-ia-agentica-que-sua-empresa-nao-deveria-terceirizar/ - Published: 2026-11-04T09:15:00.000Z - Updated: 2026-11-06T21:36:01.000Z - Author: Ibson Machado - Tags: IA, Governança **Toda empresa que eu converso este ano está comprando uma plataforma de agentes de IA de algum fornecedor de nuvem. Poucas estão perguntando o que, junto com a plataforma, estão terceirizando.** Isso não é crítica a comprar. Comprar é, na maioria dos casos, a decisão certa. O ponto é outro: existe uma camada dentro de qualquer plataforma de agentes que não deveria ser decidida por um contrato de fornecedor, porque ela é a própria definição de governança da empresa — e é justamente essa camada que a maioria compra junto, sem perceber, como parte do pacote. ## O que está acontecendo Agente de IA deixou de ser assistente de chat e virou identidade que age: abre chamado, consulta sistema, aciona outro serviço, às vezes com autonomia entre uma checagem humana e outra. Uma pesquisa da JumpCloud com empresas já mostra o descompasso: 83% das organizações hoje têm identidades não humanas rodando internamente, mas só 21% aplicam controles de governança específicos para elas. 72% já têm agentes de IA em produção; apenas 23% dizem ter maturidade de TI para gerir isso com segurança. O motivo é simples: comprar a plataforma é rápido, e a régua de sucesso do projeto é "o agente funciona", não "sabemos quem o agente representa quando ele erra". ## O risco de comprar a camada inteira Uma plataforma de agentes pronta resolve orquestração de modelo, conectores e infraestrutura de execução muito bem — é exatamente para isso que ela existe. O problema aparece quando a mesma decisão de compra também resolve, por default do fornecedor, três perguntas que não são técnicas, são de governança: - **Em nome de quem o agente age** — identidade própria ou credencial emprestada de alguém? - **O que ele pode tocar** — escopo de permissão real, ou "tudo que o conector alcança"? - **O que fica registrado quando ele erra** — trilha de auditoria com contexto suficiente para investigar, ou log genérico do fornecedor? Em setor regulado, essas três perguntas não são só de segurança da informação. São o tipo de pergunta que auditoria, regulador e — cada vez mais — o próprio conselho vão fazer depois de um incidente. O setor financeiro brasileiro já aprendeu essa lição uma vez, e não foi com agente de IA: o ataque de 2025 que desviou cerca de R$ 800 milhões de contas-reserva no Banco Central não quebrou criptografia nenhuma, usou credencial legítima de um prestador de serviço. A resposta regulatória — CMN 5.274/2025, controles estendidos a sistemas de terceiros — veio exatamente daí. Delegar a um fornecedor a definição de "quem é o agente e o que ele pode fazer" é o mesmo tipo de decisão, só que preventiva em vez de corretiva. Curiosamente, quem mais recomenda não terceirizar essa camada são os próprios fornecedores de plataforma, quando falam como consultores de governança e não como vendedores: o guia de adoção de nuvem de um dos grandes provedores lista, como primeiro princípio, dar a cada agente uma identidade distinta, aplicar privilégio mínimo e manter registro central — e recomenda que a responsabilidade por essas decisões fique com o time de governança do cliente, não embutida na configuração padrão do produto. Frameworks maduros de gestão de risco de IA (NIST AI RMF, ISO 42001) chegam à mesma conclusão por outro caminho: a função "governar" vem antes de "operar". ## O que vale a pena manter sob controle próprio Não é "escrever tudo do zero" contra "comprar tudo pronto". É sobre onde fica a fronteira de controle. Na prática, a parte que vale escrever — ou pelo menos especificar e não aceitar como caixa-preta do fornecedor — é pequena: | Vale manter sob controle próprio | Por quê | | -------------------------------------------- | ------------------------------------------------------------- | | Identidade do agente (quem ele representa) | É decisão de governança, não de infraestrutura | | Política de acesso e escopo de ação | Define o raio do erro quando ele acontece | | Trilha de auditoria com contexto de negócio | O log do fornecedor raramente responde "por quê" | | Critério e mecanismo para desligar um agente | Plano de incidente não pode depender do suporte do fornecedor | | Não vale a pena reescrever | Por quê | | ------------------------------------------------- | -------------------------------------------------------- | | Orquestração de modelo e prompt | Commodity, evolui rápido demais para manter internamente | | Parsing, embeddings, busca vetorial | Solucionado, sem vantagem competitiva em reinventar | | Infraestrutura de execução (filas, escalonamento) | Engenharia de plataforma, não de negócio | A régua não é o tamanho do código. É se a decisão embutida ali é sua de governança ou é implementação técnica substituível. ## O que fica valendo Nenhuma empresa séria vai escrever a própria orquestração de LLM em 2027 — seria como reescrever o próprio banco de dados. Mas a camada que decide quem o agente representa, o que ele pode tocar e o que fica registrado quando ele erra é pequena, é barata de manter em relação ao resto da plataforma, e é exatamente a parte que a compra "chave na mão" menos entrega, porque não é ali que o fornecedor compete. Terceirizar essa camada não é escolha técnica. É abrir mão, por omissão, da única pergunta sobre IA agêntica que o board vai fazer depois — e não antes — de alguma coisa dar errado. Sua empresa comprou a plataforma de agentes ou comprou também a definição de quem responde quando um deles errar? ## Fontes - JumpCloud / Estado de Minas (set/2026): identidades não humanas e maturidade de governança - Microsoft Cloud Adoption Framework: governança de agentes de IA - NIST AI Risk Management Framework e ISO/IEC 42001 - Incidente de 2025 no sistema financeiro e Resolução CMN 5.274/2025