top of page
ARTE 3D SEM CONTORNO_edited.png

IA in Action: quando a inteligência artificial deixa de responder e começa a executar

  • há 13 horas
  • 7 min de leitura
Este texto abre uma série de artigos sobre o SP Innovation Week 2026. A proposta é transformar anotações de palestras e painéis em análises acessíveis sobre inteligência artificial, inovação e transformação digital.

Evento: SP Innovation Week 2026

Data: 13 a 15 de maio de 2026

Locais: Mercado Livre Arena Pacaembu e FAAP

Trilha: IA in Action

Tema do artigo: agentes de IA, governança, escala e execução empresarial


Entre os dias 13 e 15 de maio de 2026, o São Paulo Innovation Week 2026 ocupou dois espaços simbólicos de São Paulo: a Mercado Livre Arena Pacaembu e a FAAP. A programação reuniu debates sobre inovação, tecnologia, negócios, educação, saúde e inteligência artificial. Na trilha AI in Action, a curadoria trouxe discussões sobre futuro da IA, regulação, aplicações práticas, autonomia de agentes e uso da tecnologia em áreas como saúde e negócios.


A primeira palestra acompanhada na trilha IA in Action girou em torno de uma ideia simples, mas poderosa: a inteligência artificial nas empresas está deixando de ser apenas uma interface de conversa para se tornar uma camada de execução.


A frase que resume bem essa transição é esta:

Chatbot responde. Assistente apoia. Agente executa.


Em resumo: a discussão não é mais apenas sobre conversar com a IA, mas sobre permitir que ela participe de processos reais de trabalho, com limites, supervisão e responsabilidade.

Essa distinção é importante porque muita gente ainda trata tudo como se fosse “chatbot”. Mas a discussão apresentada na trilha IA in Action, com participação de representantes do Estadão e convidados, mostrou que o debate já está em outro estágio. Um chatbot tradicional interage por perguntas e respostas. Um assistente ajuda a organizar informações, escrever textos, resumir documentos ou apoiar decisões. Já um agente de IA vai além: ele pode receber um objetivo, dividir a tarefa em etapas, acionar ferramentas, consultar sistemas e executar parte do fluxo com menor intervenção humana. Em outras palavras, a diferença está no grau de autonomia: o chatbot conversa, o assistente apoia e o agente atua dentro de um processo.


Um exemplo ajuda a visualizar essa diferença. Em uma área de atendimento, um chatbot responde dúvidas frequentes. Um assistente ajuda o atendente a resumir o histórico do cliente. Um agente, por sua vez, pode abrir um chamado, consultar o status do pedido, acionar uma política de reembolso e registrar a ação no sistema — desde que tenha permissão para isso.


O agente como um novo funcionário


Uma das analogias mais interessantes da palestra foi comparar o agente de IA ao onboarding de um funcionário.


Quando uma pessoa entra em uma empresa, ela não recebe apenas uma mesa e um crachá. Ela precisa aprender:


  • quais ferramentas usar;

  • quais regras seguir;

  • quem aprova o quê;

  • onde estão os dados confiáveis;

  • quais decisões pode tomar sozinha;

  • quando precisa escalar o problema para alguém.


Com os agentes de IA, a lógica é parecida. Não basta conectar um modelo de linguagem a um sistema corporativo e esperar que ele “se vire”. O agente precisa ser treinado ou configurado dentro de um ambiente com diretrizes de uso, permissões, limites, auditoria e monitoramento.


Esse ponto é central para empresas que querem sair do entusiasmo inicial e chegar à escala. A McKinsey mostra que o uso de IA cresceu nas organizações, mas a passagem de pilotos para impacto em escala ainda é um desafio. Segundo a pesquisa global de 2025, 88% dos respondentes afirmam que suas organizações usam IA regularmente em ao menos uma função, mas apenas cerca de um terço começou a escalar programas de IA no nível empresarial.

Adoção orgânica não basta


Outro ponto forte da palestra foi a crítica à ideia de que a adoção de IA acontecerá naturalmente. A mensagem foi direta: adoção orgânica não funciona quando o objetivo é escala, segurança e impacto mensurável.


Em uma empresa, deixar cada área experimentar ferramentas por conta própria pode gerar aprendizado inicial, mas também cria riscos: duplicidade de soluções, uso indevido de dados, custos invisíveis, baixa governança e dificuldade para medir resultados.


Por isso, a palestra destacou três dimensões que precisam caminhar juntas:


  • Adoção, para que as pessoas realmente usem a tecnologia no trabalho.

  • Escala, para que o uso não fique preso a pequenos pilotos.

  • Risco, para que a empresa saiba onde a IA pode errar, extrapolar ou gerar problemas jurídicos, operacionais ou reputacionais.


Essa visão está alinhada com estudos recentes sobre IA corporativa. A McKinsey aponta que empresas de melhor desempenho em IA tendem a redesenhar fluxos de trabalho, envolver lideranças e estruturar práticas de gestão em estratégia, talentos, modelo operacional, tecnologia, dados, adoção e escala.

Um novo tipo de liderança: humanos e agentes


A palestra também provocou uma mudança de imagem sobre liderança. Em vez de pensar apenas em líderes gerenciando pessoas, surge o cenário de líderes organizando equipes híbridas, formadas por humanos e agentes.


O exemplo do squad ajuda a visualizar essa mudança. No modelo tradicional, um squad podia reunir pessoas com papéis diferentes: produto, tecnologia, dados, design, negócio. No novo cenário, uma única pessoa pode coordenar múltiplos agentes especializados: um agente para pesquisa, outro para documentação, outro para análise de dados, outro para testes, outro para atendimento.


A ideia de “one pizza team”, usada em tecnologia para falar de equipes pequenas o bastante para serem alimentadas por uma pizza, ganha outra interpretação. A equipe pode continuar pequena em número de pessoas, mas ampliar sua capacidade operacional por meio de agentes.


Esse ponto é compatível com a discussão do BCG sobre IA agêntica. A consultoria argumenta que agentes de IA desafiam o modelo tradicional de gestão porque combinam características de ferramenta e de “colega operacional”. Por isso, exigem redesenho de fluxos, papéis, governança e direitos de decisão.

Guardrails, auditoria e telemetria


Quando agentes começam a agir, a empresa precisa deixar de pensar apenas em prompt e começar a pensar em operação.


Isso envolve três camadas importantes:


  • Guardrails, ou limites de atuação. Eles definem o que o agente pode e não pode fazer.

  • Auditoria, para registrar decisões, ações e justificativas.

  • Telemetria, para acompanhar desempenho, custo, erros, tempo de resposta, uso de ferramentas e eventuais comportamentos inesperados.


O BCG recomenda que empresas tratem agentes de IA como produtos operacionais, com supervisão humana, logs, explicabilidade, controle de mudanças e capacidade de rollback. A recomendação é clara: controles não devem ser adicionados depois de incidentes, mas incorporados desde o desenho da solução.


O gargalo do custo: tokens, modelos e eficiência


Outro tema relevante foi o custo. Quando uma empresa começa a multiplicar agentes, surge uma pergunta prática: quem paga a conta dos tokens?

Cada agente pode consumir chamadas a modelos de linguagem, bases vetoriais, APIs, ferramentas internas e sistemas externos. Em pequena escala, isso pode parecer administrável. Em larga escala, pode virar um gargalo financeiro e arquitetural.


Daí a discussão sobre SLMs, ou Small Language Models. Esses modelos menores podem ser mais eficientes para tarefas específicas, consumindo menos recursos computacionais que modelos grandes. A Microsoft define SLMs como modelos de linguagem projetados para tarefas específicas usando menos recursos, com benefícios como menor custo, menor consumo de energia e melhor desempenho em aplicações de domínio específico.


Isso não significa substituir todos os LLMs por modelos menores. A decisão mais madura parece ser outra: usar o modelo certo para a tarefa certa. Nem toda tarefa exige o maior modelo disponível. Algumas precisam de raciocínio complexo; outras precisam apenas de classificação, extração, roteamento ou consulta estruturada.

O conflito com a indústria SaaS


Um dos pontos mais sensíveis das anotações foi a menção à indústria de software como serviço, especialmente o caso da SAP.


A questão é estratégica: se agentes de IA passam a operar sistemas corporativos por meio de APIs, eles podem alterar o equilíbrio de poder entre clientes, fornecedores de software e plataformas de IA.


Em abril de 2026, a SAP atualizou sua política de APIs e passou a restringir o uso de APIs por sistemas generativos ou semi-autônomos capazes de planejar, selecionar ou executar sequências de chamadas fora de arquiteturas aprovadas pela própria SAP. A mudança gerou preocupação sobre possível lock-in, ou seja, maior dependência dos clientes em relação ao ecossistema autorizado pela empresa.


Esse exemplo ajuda a entender por que a palestra comparou o momento atual à adoção da internet. No início da internet comercial, empresas precisaram rever canais, modelos de negócio, integração com clientes e acesso a dados. Agora, com agentes de IA, a disputa pode estar em outro lugar: quem controla a execução dos processos digitais.


“Proibido fazer código na mão”


Uma das frases mais provocativas das anotações foi: “proibido fazer código na mão”. Como slogan, a frase funciona. Ela expressa uma mudança cultural: em algumas áreas, programar pode deixar de ser apenas escrever linha por linha e passar a ser descrever intenções, revisar saídas, testar hipóteses, integrar componentes e supervisionar agentes de desenvolvimento. Mas, como afirmação literal, ela precisa de cuidado. Código gerado por IA ainda precisa de revisão, testes, segurança, arquitetura e responsabilidade técnica. A própria palestra parece apontar para isso quando menciona auditoria, guardrails, telemetria e gestão de mudança.


A leitura mais equilibrada seria:

O profissional não desaparece. Ele muda de função: deixa de ser apenas executor manual e passa a ser orquestrador, revisor e responsável pela qualidade do sistema.

A principal mensagem da palestra


A primeira palestra da trilha IA in Action mostrou que a discussão sobre IA nas empresas está amadurecendo. O tema já não é apenas “qual ferramenta usar”, mas como redesenhar o trabalho para que humanos e agentes atuem juntos com segurança, escala e impacto real.


O agente de IA não deve ser visto como mágica, nem como simples chatbot com nome novo. Ele é uma nova camada operacional. Pode executar tarefas, mas precisa de contexto. Pode aumentar produtividade, mas exige governança. Pode reduzir esforço humano, mas aumenta a responsabilidade sobre desenho de processos, custos, auditoria e liderança.


A grande pergunta que fica é: as empresas estão preparando seus agentes como preparariam um novo funcionário, com treinamento, limites, ferramentas e supervisão, ou estão apenas colocando IA em produção sem modelo de gestão?

Perguntas para levar à empresa


  • Quais tarefas repetitivas poderiam ser delegadas a agentes de IA?

  • Quais sistemas esses agentes precisariam acessar?

  • Quais dados eles poderiam consultar?

  • Quem auditaria suas decisões?

  • Como medir custo, produtividade e risco?

  • O que nunca deveria ser executado sem aprovação humana?

Para finalizar, quero agradecer ao Rafael Siqueira da Mckinsey & Company pelo conhecimento compartilhado.


Glossário rápido

Agente de IA

Sistema de IA capaz de executar tarefas com certo grau de autonomia, usando ferramentas, dados e instruções.

Chatbot

Sistema voltado principalmente para conversa, perguntas e respostas.

Assistente de IA

Ferramenta que apoia o usuário em tarefas como resumir, escrever, pesquisar ou organizar informações.

Guardrails

Regras, limites e mecanismos de segurança que orientam o que a IA pode ou não pode fazer.

Telemetria

Monitoramento técnico do uso da IA, incluindo erros, custos, tempo de resposta e comportamento do sistema.

Token

Unidade de texto processada por um modelo de IA. O custo de uso geralmente está relacionado à quantidade de tokens consumidos.

LLM

Grande modelo de linguagem, treinado com grandes volumes de dados e usado para tarefas amplas de compreensão e geração de texto.

SLM

Modelo de linguagem menor, geralmente mais eficiente para tarefas específicas.

API

Interface que permite que sistemas diferentes conversem entre si.

Lock-in

Situação em que uma empresa fica muito dependente de um fornecedor, produto ou plataforma.



Comentários


bottom of page