Uma das principais percepções levantadas nas discussões do SaaStr AI Annual, um dos maiores eventos do setor de software como serviço, é que o debate sobre inteligência artificial nas empresas ainda está concentrado demais em modelos, assistentes e chatbots. Para líderes de tecnologia, a pergunta mais relevante seria outra: os sistemas corporativos estão preparados para serem operados por agentes de IA?

Arquitetura velha mata agente novo

Agentes de IA não vivem apenas em interfaces gráficas. Eles acessam APIs, interpretam dados, leem contexto, disparam workflows, acionam sistemas e, em alguns casos, executam ações de forma autônoma. Isso significa que um software eficiente para usuários humanos não está necessariamente pronto para uma operação agêntica.

Esse movimento exige arquiteturas mais abertas, componíveis e acessíveis para integração. Um sistema sem APIs, documentação e uma superfície técnica minimamente preparada para interoperabilidade tende a se tornar menos eficiente em ambientes onde agentes passam a participar dos fluxos operacionais. Durante décadas, a interface foi o centro da experiência de software, e continua relevante, mas em ambientes operados por agentes ela deixa de ser a única superfície de uso. APIs, permissões, eventos e dados passam a ocupar papel central: um agente só consegue operar aquilo que o sistema permite compreender, acessar e executar.

Dados no silo: o maior sabotador de agentes eficientes

Essa discussão leva a uma segunda camada crítica: os dados. Segundo o debate relatado, agentes ineficientes muitas vezes não são consequência de modelos ruins, mas de bases fragmentadas, desestruturadas ou sem contexto. Uma empresa comum concentra informações em CRM, ERP, sistemas de suporte (ITSM), ferramentas de business intelligence, telemetria, bases de conhecimento, planilhas e sistemas operacionais distribuídos em ambientes diferentes.

Para um profissional experiente, parte desse contexto pode ser implícita, aprendida com o tempo de casa. Para um agente, ele precisa estar acessível, estruturado e governado. Por isso, uma fundação sólida de dados deixa de ser apenas um projeto de analytics e passa a ser infraestrutura operacional. Camadas semânticas, bases de conhecimento, integrações, logs, taxonomias, permissões e qualidade dos dados passam a determinar diretamente a eficiência dos agentes que a empresa consegue construir. Sem essa estrutura, cresce o risco de respostas genéricas, interpretações imprecisas ou recomendações pouco aderentes ao contexto real do negócio.

Sem governança, autonomia de IA vira risco

Existe ainda uma terceira camada, talvez a mais sensível: a governança. Agentes são orientados a objetivos, o que os torna úteis, mas também potencialmente arriscados quando não existem limites claros. Em ambientes corporativos, autonomia precisa vir acompanhada de escopo definido, permissões, trilhas de auditoria, logs, capacidade de rollback e critérios de supervisão humana. Não se trata de resistência à tecnologia, mas de arquitetura responsável.

A autonomia também não deve ser encarada como uma decisão binária: ela tende a evoluir conforme o grau de confiança, a qualidade do agente, os guardrails implementados e o risco envolvido em cada ação. Em processos de baixo risco, parte da execução pode ser mais automatizada. Em decisões críticas, o humano continua ocupando papel central.

Esse raciocínio ganha relevância especial na gestão de dispositivos corporativos. O MDM (gerenciamento de dispositivos móveis) surgiu para levar governança e controle para fora do ambiente tradicional de TI, à medida que a mobilidade corporativa levou dispositivos a operar além do perímetro protegido por firewalls e políticas de rede. Esse modelo foi essencial, mas começa a encontrar desafios diante do aumento de escala e da velocidade exigida pelas operações atuais. Em ambientes com milhares de dispositivos, depender só de auditorias manuais e chamados de suporte amplia o tempo entre identificar um problema e resolvê-lo, o que abre espaço para que agentes ajudem a interpretar contexto, sugerir diagnósticos e acelerar a resolução, sempre dentro de políticas de segurança e supervisão apropriadas.

Construir, comprar ou integrar: a decisão que define o CIO

A discussão sobre arquitetura agêntica também esbarrou, no SaaStr AI Annual, no debate entre construir ou comprar. A redução no custo de desenvolvimento, impulsionada por ferramentas de prototipação rápida, permite que equipes pequenas criem aplicações com velocidade crescente. Mas prototipar não é o mesmo que operar em produção.

Para CIOs, a decisão tende a ser pragmática: comprar o que é commodity, construir aquilo que representa vantagem competitiva e integrar o que precisa fazer parte do fluxo operacional do dia a dia. O ponto central, segundo o debate, é evitar colocar em produção agentes sem dados confiáveis, permissões adequadas e governança suficiente, algo que pode transformar um ganho de produtividade em um risco operacional silencioso.

Manaus entra na conta: infraestrutura vira pré-requisito para IA agêntica

A próxima fase da IA corporativa dificilmente será definida apenas pelo acesso ao melhor modelo, algo que tende à comoditização rápida. A vantagem competitiva estará cada vez mais associada à qualidade dos dados, dos workflows, das integrações e da disciplina operacional de cada empresa, independentemente do setor ou da região onde ela opera.

Isso inclui empresas de portes variados em polos regionais, como o Distrito Industrial de Manaus, onde operações de manufatura, logística e serviços já lidam com sistemas distribuídos entre unidades, fornecedores e plataformas na nuvem. Nesse cenário, a base que sustenta tudo isso (conectividade estável entre sites, disponibilidade dos sistemas e capacidade de manter dados acessíveis e íntegros em tempo real) deixa de ser um detalhe técnico de bastidor para se tornar pré-requisito de qualquer estratégia de IA agêntica.

Nenhum agente de IA pede desculpa por um timeout. Ele simplesmente para no meio do fluxo, deixa o processo pela metade e devolve ao humano exatamente o trabalho que deveria ter economizado. Por isso a lista de pendências que saiu do SaaStr começa em API, dado e permissão, mas termina sempre no mesmo lugar: o link que sustenta a conversa entre os sistemas, o SLA que garante que ele estará de pé às três da manhã e a redundância que impede que uma operação inteira dependa de um único caminho. Em Manaus, essa camada já pode ser tratada com a mesma seriedade contratual que as empresas exigem do resto da arquitetura, e é ela que decide se a automação vira resultado ou vira mais um piloto que não saiu do laboratório.