Seu agente de IA não tem identidade. E isso é um problema.

Passamos os últimos dois anos tornando os agentes de IA mais capazes. Eles conseguem fazer consultas em bancos de dados, resumir documentos, direcionar fluxos de trabalho e iniciar Transactions em seu nome. Alguns deles são genuinamente impressionantes.
O desafio mais difícil é o que a maioria das organizações ainda não resolveu: garantir que eles sejam responsabilizáveis.
Um agente pode agir. Mas responsabilização é uma questão completamente diferente. Quando um funcionário realiza uma ação, há uma cadeia de identidade associada a ela. Quando um agente faz o mesmo, muitas vezes essa cadeia não existe. À medida que os agentes migram de demonstrações para ambientes de produção, essa lacuna se torna um problema de governança.
É o problema de identidade dos agentes. Um agente deve ter uma identidade verificável própria: direitos definidos, escopo definido e um registro persistente do que fez. Sem isso, você não consegue responder o que aconteceu, quem autorizou ou se o agente permaneceu dentro dos seus limites, e isso se torna um risco no momento em que algo dá errado.
A maioria não tem. E essa lacuna já está freando a adoção em alguns dos programas de IA mais sofisticados do mundo.
As perguntas que toda equipe de conformidade precisa responder
Em setores regulados, a IA não reduz a complexidade das auditorias. Ela a amplifica. Se um agente faz uma consulta no seu banco de dados, gera uma recomendação ou inicia uma ação, e algo der errado daqui a seis meses, sua equipe precisará responder:
Quem criou o agente?
Quais eram seus direitos e por quanto tempo?
Quais dados ele acessou?
E se ele gerou um insight derivado (uma projeção, um resumo, um resultado que ninguém autorizou explicitamente, por exemplo), quem é o responsável?
Imagine um agente de análise de crédito para concessão de empréstimos. Ele consulta dados de crédito, sinaliza riscos e produz uma recomendação de aprovação. Um ano depois, um tomador de empréstimo contesta o resultado. Sua equipe de conformidade precisa reconstruir exatamente quais dados o agente acessou, sob qual autoridade e se o resultado permaneceu dentro do escopo aprovado. Se esse registro não existir, você não está apenas exposto. Você está começando do zero.
Parecem perguntas razoáveis. O problema é que a maioria das infraestruturas de identidade não foi projetada para respondê-las.
Por que é mais difícil do que parece
Os sistemas de identidade tradicionais foram criados para funções estáveis e acessos definidos. Os agentes não se encaixam nesse modelo.
Um agente pode ser iniciado para uma única tarefa, acessar quatro fontes de dados e desaparecer antes do meio-dia. Cada fonte pode ter tido controles de acesso adequados de forma isolada. Mas o resultado combinado, um insight derivado, pode ultrapassar limites que ninguém autorizou. O agente fez exatamente o que foi criado para fazer. O problema foi que ninguém definiu o limite.
E mesmo depois que um agente deixa de existir, o registro ainda precisa existir.
Pense em um processo batch agendado tradicional, um script de folha de pagamento que roda toda noite à meia-noite. Ele tem um nome, um responsável, um histórico de auditoria completo. E um agente dinâmico que rodou por três horas e retornou uma recomendação? Sem uma arquitetura intencional, ele deixa quase nenhum rastro de governança.
Resolver a identidade dos agentes começa com a incorporação da governança na arquitetura
A governança não pode ser adicionada depois. Ela precisa fazer parte da arquitetura desde o início.
Veja como isso funciona na prática:
- Identidade na criação, não no runtime. Os direitos, o acesso a dados e o escopo operacional de um agente precisam ser definidos antes de ele agir, não inferidos a partir do usuário que o invocou. Permissões explícitas com prazo de validade incluem o que ele pode acessar, por quanto tempo e em nome de quem. Por exemplo, um agente invocado por um VP de Finanças recebe seu próprio acesso com escopo definido, não uma cópia herdada do acesso do VP.
- Governança sobre outputs, não apenas inputs. Controles de acesso nos dados de origem não são suficientes. Quando os agentes combinam dados de diferentes sistemas, o resultado combinado pode ultrapassar limites que nenhuma fonte individual ultrapassaria. As políticas precisam acompanhar os insights derivados, não apenas os dados que os originaram. Um agente autorizado a acessar dados de RH e dados financeiros separadamente pode não estar autorizado a combiná-los.
- Rastreamento do ciclo de vida que sobrevive ao agente. Agentes de curta duração ainda precisam de um registro permanente de quem os criou, o que acessaram, o que produziram e quem os autorizou. A auditabilidade não pode depender de o agente ainda estar em execução. Um agente clínico que rodou por uma hora e retornou uma recomendação ainda precisa de um registro permanente.
- Supervisão humana como alerta, não como muleta. O objetivo não é ter um humano monitorando cada interação do agente. Isso anula o propósito. O modelo correto é uma revisão periódica e sistemática, com uma função de auditoria que detecta desvios antes que se acumulem. Pense nisso como uma auditoria financeira: não é necessário analisar cada transação, mas o suficiente para identificar padrões.
É por isso que esses princípios estão incorporados ao Snowflake por design, orientando o desenvolvimento dos nossos próprios agentes de IA e dos agentes que habilitamos nossos clientes a criar.
Quando desenvolvemos nosso próprio Snowflake Go-To-Market AI Assistant, queríamos capacitar nossas equipes com todo o conhecimento de vendas relevante, histórias de clientes e insights de contas ao alcance das mãos. Para que isso funcionasse, precisávamos acertar em dois pontos: garantir que as informações fornecidas fossem confiáveis e implementar controles para que o agente expusesse apenas as informações certas para as pessoas certas no momento certo.
Por isso, começamos com estes itens como restrições de design, não como funcionalidades:
- Acesso a dados baseado em funções
- Consultas certificadas que distinguem respostas validadas de inferidas
- Escopo definido na criação
- Um modelo de dados lógico que aplica o controle de acesso a dados em múltiplas fontes
O resultado: nosso agente agora capacita mais de 6.000 colaboradores e responde a mais de 35.000 perguntas por semana, um agente em que nossas equipes confiam para operar de forma autônoma, com auditabilidade completa após o fato.
Na mesma escala, apoiamos nossos clientes da mesma forma. Clientes de empresas como TS Imagine, Fanatics e United Rentals estão todos criando agentes no Snowflake para acelerar seus negócios.
A Tipalti, uma plataforma global de pagamentos que processa mais de USD 75 bilhões em Transactions anuais, por exemplo, usa o Snowflake AI Data Cloud para democratizar a exploração de dados alimentada por LLM (Large Language Model) em suas equipes. A plataforma permite que as principais unidades de negócios acelerem insights financeiros e tomem decisões críticas com mais agilidade, economizando tempo e recursos e capacitando as pessoas mais próximas do trabalho com as informações de que precisam para agir com confiança.
Resolver a identidade dos agentes é a chave para a adoção da IA para empresas
Resolver a identidade dos agentes não apenas reduz riscos. Também elimina o atrito que está freando a adoção.
Hoje, o medo do desconhecido é o que leva as empresas a designar um humano para monitorar cada agente, criar aplicações em vez de agentes verdadeiros ou evitar a categoria por completo. Isso é caro. E anula o propósito.
Essa hesitação desaparece quando você consegue responder quem é o agente, o que ele está autorizado a fazer e o que ele realmente fez. Os agentes conquistam confiança da mesma forma que as pessoas. Não pela intenção. Mas pela evidência.
A capacidade já não é o obstáculo. A confiança é.
