Quando uma empresa anuncia uma parceria de inteligência artificial, a narrativa costuma seguir um roteiro previsível. De um lado está o fornecedor de tecnologia. Do outro, o cliente que contrata a plataforma, recebe ferramentas e tenta aplicá-las aos seus processos.
Essa divisão parece lógica, mas limita o potencial da colaboração. Ela sugere que a capacidade está concentrada em quem oferece o modelo, a nuvem ou o software, enquanto a outra parte apenas consome. Na prática, os projetos mais relevantes dependem de uma troca muito mais equilibrada.
A empresa de tecnologia conhece modelos, infraestrutura digital, integração e segurança. A organização que domina um setor conhece materiais, clientes, restrições, exceções, riscos e decisões que não aparecem em uma demonstração. Sem esse conhecimento de domínio, a IA pode ser tecnicamente sofisticada e operacionalmente ingênua.
Uma parceria anunciada por 3M e Microsoft em 15 de julho de 2026 oferece um exemplo interessante dessa relação de mão dupla. A Microsoft pretende utilizar uma tecnologia de conexão óptica desenvolvida pela 3M em sua infraestrutura de nuvem e IA. Ao mesmo tempo, a 3M pretende utilizar recursos digitais e de inteligência artificial da Microsoft em áreas como atendimento, finanças, vendas e marketing.
O anúncio não comprova resultados. Ele descreve compromissos, aplicações planejadas e uma colaboração em desenvolvimento. Ainda assim, revela uma forma mais madura de pensar a transformação: cada organização entra com uma competência que a outra não possui na mesma profundidade.
O que foi anunciado
Segundo a publicação conjunta, a Microsoft será o primeiro provedor de nuvem em escala global anunciado como adotante da tecnologia Expanded Beam Optical, criada pela 3M. O componente foi desenvolvido para conexões de fibra em ambientes densos, sujeitos a poeira, manuseio e manutenção.
A 3M, por sua vez, pretende incorporar plataformas de IA e recursos digitais da Microsoft em funções empresariais. O exemplo mais concreto apresentado envolve a gestão de pedidos de clientes. Engenheiros das duas organizações estão colaborando em um fluxo com agentes de IA para apoiar verificações de crédito, avaliações de inadimplência e atualizações de sistemas.
O comunicado informa que o desenho inclui controles humanos e um painel de monitoramento para visibilidade e aprovação. Também descreve benefícios esperados, como menor esforço manual, maior velocidade e mais consistência. Como a solução ainda está sendo desenvolvida, essas expectativas não devem ser tratadas como desempenho realizado.
Essa distinção é essencial. Uma parceria pode indicar direção estratégica sem fornecer evidência de impacto. O valor editorial do anúncio está menos nas promessas e mais na arquitetura da colaboração: tecnologia física melhora a infraestrutura digital, enquanto tecnologia digital transforma um processo empresarial.
A empresa não é apenas cliente da IA
Toda organização possui ativos de conhecimento que podem ser tão importantes quanto o modelo utilizado. Parte desse conhecimento está documentada em procedimentos, contratos, sistemas e manuais. Outra parte vive na experiência das pessoas.
Um profissional sabe quais exceções exigem atenção. Um supervisor reconhece quando um pedido aparentemente comum apresenta risco. Uma equipe de atendimento conhece as palavras que indicam urgência. Um engenheiro entende por que uma solução adequada em laboratório pode falhar no ambiente de produção.
Esse repertório não é um detalhe a ser acrescentado depois. Ele define o problema, os limites e os critérios de sucesso. Quando a empresa assume apenas o papel de compradora, corre o risco de entregar dados e processos ao fornecedor sem participar suficientemente do desenho da solução.
Uma parceria produtiva transforma o conhecimento do negócio em requisito técnico. As regras deixam de ser explicações informais e passam a orientar testes, mecanismos de validação, pontos de aprovação e respostas a falhas.
Isso também muda a relação comercial. A pergunta deixa de ser apenas qual ferramenta será contratada. Passa a ser qual competência cada parte oferece, quais decisões serão compartilhadas e como o aprendizado produzido pelo projeto permanecerá dentro da organização.
Conhecimento de domínio não pode ser terceirizado
Modelos de IA conseguem identificar padrões, resumir documentos e propor ações. Eles não assumem automaticamente a responsabilidade de compreender todas as consequências de uma decisão.
No exemplo anunciado, verificações de crédito e avaliações de inadimplência fazem parte de um processo que afeta pedidos, relacionamento com clientes e fluxo financeiro. Um agente pode organizar informações e apoiar a análise, mas a definição das regras, das exceções e das alçadas pertence à organização.
O NIST, em seu AI Risk Management Framework, recomenda que o contexto de uso seja mapeado e que as responsabilidades nas configurações entre pessoas e sistemas de IA sejam definidas. O Playbook também destaca a participação de especialistas que compreendam o domínio, as pessoas afetadas e as condições reais de operação.
Essa orientação ajuda a evitar um erro comum: tratar conhecimento de domínio como um conjunto de documentos que basta enviar ao modelo. Documentos são importantes, mas não capturam todas as ambiguidades, mudanças e decisões tácitas presentes no trabalho.
Especialistas precisam participar da criação dos casos de teste, da análise de falhas e da definição dos limites. Também devem poder contestar resultados que pareçam coerentes para o sistema, mas contrariem a realidade operacional.
O fluxo deve ser desenhado antes do agente
A expressão agente de IA pode levar equipes a começar pela tecnologia. Escolhem um sistema capaz de executar tarefas e só depois procuram onde utilizá-lo. Uma abordagem mais segura começa pelo fluxo.
Quem inicia a atividade? Quais informações são necessárias? De onde elas vêm? Que regra transforma informação em recomendação? Em que momento uma pessoa precisa revisar? Qual sistema recebe a atualização? O que acontece quando os dados estão incompletos ou contraditórios?
Essas perguntas revelam que uma automação não é uma sequência linear. Existem desvios, pendências, exceções e diferentes níveis de autoridade. Um agente que funciona apenas no caminho ideal não está pronto para a operação.
O comunicado da parceria menciona visibilidade em tempo real e aprovações humanas. Esses elementos indicam uma preocupação correta, mas sua eficácia dependerá do desenho concreto. Um painel não cria governança sozinho. Ele precisa mostrar as informações certas para a pessoa certa e permitir uma intervenção compreensível.
Também é necessário decidir o que o agente pode fazer sem autorização. Consultar dados, organizar evidências e preparar uma recomendação apresentam riscos diferentes de alterar um limite, bloquear um pedido ou atualizar um sistema financeiro.
Autonomia deve ser concedida por etapa, não por entusiasmo. A organização pode começar com observação, avançar para recomendação e liberar ações apenas quando houver evidência suficiente de qualidade, segurança e capacidade de recuperação.
Parceria não é transferência de dependência
Trabalhar com uma grande empresa de tecnologia pode acelerar um projeto, mas não elimina a necessidade de competência interna. Pelo contrário, quanto mais relevante a solução se torna, maior deve ser a capacidade da organização de compreendê-la.
A empresa precisa saber quais dados sustentam as decisões, quais integrações são críticas e quais mudanças podem afetar o comportamento do sistema. Também deve manter documentação sobre regras, versões, responsabilidades e incidentes.
Se apenas o fornecedor consegue explicar a solução, a parceria criou dependência. Se a equipe interna consegue operar, questionar, medir e evoluir o fluxo, a parceria criou capacidade.
Isso não significa reproduzir toda a tecnologia dentro da empresa. Significa preservar conhecimento suficiente para tomar decisões informadas. A organização deve conseguir trocar um componente, revisar uma regra ou interromper uma ação sem perder o controle do processo.
Contratos e acordos de colaboração precisam refletir essa preocupação. Propriedade dos dados, acesso a registros, responsabilidade por atualizações, continuidade do serviço e portabilidade não são temas administrativos separados da IA. Eles definem a liberdade futura da empresa.
O aprendizado precisa permanecer na organização
Projetos de IA produzem conhecimento mesmo quando não chegam à implantação. Eles revelam problemas de dados, ambiguidades de processo, controles frágeis e tarefas que dependem de poucas pessoas.
Esse aprendizado não deve ficar restrito à equipe do piloto ou ao parceiro tecnológico. Precisa ser transformado em documentação, treinamento e critérios reutilizáveis.
Uma boa parceria deixa artefatos claros: mapa do processo, catálogo de dados, conjunto de testes, registro de decisões, biblioteca de exceções e plano de monitoramento. Esses elementos permitem que outros casos de uso avancem com mais qualidade.
Também ajudam a empresa a separar o que pertence à tecnologia e o que pertence à gestão. Se o projeto falha porque um cadastro está desatualizado, trocar o modelo não resolve. Se as áreas discordam sobre a regra, aumentar a capacidade computacional não resolve. Se ninguém possui autoridade para decidir uma exceção, o agente apenas acelera a confusão.
O valor da colaboração aparece quando ela melhora a organização, não apenas quando entrega uma automação.
Como estruturar uma colaboração de mão dupla
O primeiro passo é listar as competências de cada parte. O fornecedor pode oferecer modelos, infraestrutura, integração, segurança e experiência com projetos semelhantes. A empresa traz conhecimento setorial, acesso ao processo, dados, especialistas e capacidade de validar consequências.
O segundo é definir um problema com fronteiras claras. A equipe deve saber qual decisão será apoiada, quais sistemas serão envolvidos e quais resultados serão observados. Expressões genéricas como transformar o atendimento ou automatizar finanças dificultam o alinhamento.
O terceiro é criar um grupo de desenho realmente multidisciplinar. Tecnologia, operação, negócio, segurança, jurídico e usuários do processo precisam participar conforme o risco. A presença de diferentes áreas não deve ser apenas consultiva. Cada uma precisa ter responsabilidades definidas.
O quarto é construir casos de teste antes da escala. Exemplos frequentes são necessários, mas exceções e situações adversas revelam melhor os limites. Dados ausentes, clientes com condições especiais, divergências entre sistemas e solicitações urgentes precisam fazer parte da avaliação.
O quinto é definir autonomia e aprovação por ação. A organização deve registrar o que a IA observa, recomenda, prepara e executa. Para cada nível, deve existir um responsável e um procedimento de reversão.
O sexto é acompanhar o comportamento do sistema e o efeito no processo. Qualidade da recomendação, frequência de intervenção humana, tipos de erro e incidentes importam tanto quanto velocidade. Métricas só devem ser escolhidas quando estiverem ligadas a uma decisão.
Por fim, o projeto deve ter um plano de transferência de conhecimento. Equipes internas precisam aprender a operar e questionar a solução. O parceiro precisa receber retorno suficiente para compreender o contexto. A colaboração amadurece quando ambos os lados se tornam melhores.
O que líderes devem perguntar antes de assinar
Antes de anunciar uma parceria, a liderança deveria responder a algumas perguntas simples.
Qual conhecimento exclusivo nossa empresa oferece ao projeto? Quem possui esse conhecimento? Como ele será transformado em regras, testes e controles? Quais capacidades continuaremos dominando internamente? Que decisões permanecerão humanas? Como veremos o que o sistema fez? Como interromperemos ou reverteremos uma ação? O que aprenderemos mesmo que o piloto não avance?
Essas perguntas ajudam a distinguir uma parceria estratégica de uma compra ampliada. A compra entrega acesso. A parceria constrói uma capacidade compartilhada.
Também protegem a organização do efeito demonstração. Uma solução pode parecer impressionante em uma apresentação e fracassar quando encontra dados incompletos, integrações antigas e decisões disputadas. O conhecimento de domínio é o que transforma a demonstração em operação.
Conclusão
O anúncio entre 3M e Microsoft mostra uma ideia que merece ser observada: na transformação com IA, nenhuma das partes possui sozinha tudo o que o projeto exige. A infraestrutura digital depende de conhecimento físico e industrial. A modernização da operação depende de modelos, integração e governança.
Na minha visão, empresas deveriam entrar em parcerias de inteligência artificial menos preocupadas em parecer consumidoras de tecnologia e mais conscientes do valor que já possuem. Processos, experiência, relacionamento com clientes e conhecimento acumulado são ativos estratégicos. Quando são tratados apenas como dados de entrada, a organização perde poder de decisão.
A parceria mais valiosa não é aquela em que um fornecedor entrega respostas prontas. É aquela em que o conhecimento circula nos dois sentidos, os limites ficam claros e a empresa termina o projeto mais capaz do que começou.
IA com propósito não nasce da dependência. Nasce da combinação entre competências diferentes, responsabilidade compartilhada e aprendizado que permanece.