A analogia mais óbvia para a IA na integração corporativa é, claro, uma festa de aniversário infantil. Minha filha queria panquecas na festa dela. Imagine que eu tivesse contratado um robô para prepará-las.

O robô saberia fazer panquecas. Mas não saberia decidir quais preparar. De que tipo? Com quais acompanhamentos? Como agradar a todos os convidados? A mãe dela queria garantir que houvesse frutas. Preparar as panquecas nunca foi a parte difícil. O desafio era decidir o que preparar e para quem. Ninguém se importaria com o funcionamento do robô. O que importaria seria o que chegaria ao prato de cada pessoa.

As integrações criadas com IA levantam uma questão semelhante, mas com consequências muito maiores. A IA está começando a demonstrar sua capacidade de gerar código. Agora, as lideranças estão incentivando profissionais de todos os departamentos a encontrar oportunidades de eficiência com IA. Isso deixa os líderes de integração diante de duas perguntas:

Podemos confiar na IA para gerar código de integração?

O código é, de fato, o nível de abstração adequado para o trabalho de integração?

Os líderes de integração enfrentam há muito tempo uma demanda crescente com orçamentos limitados. O avanço da IA aumentou as expectativas, tanto em relação ao volume de entregas quanto à velocidade. Além dos workflows determinísticos, agora também existe a demanda por workflows agênticos. Eles utilizam modelos de linguagem de grande escala (LLMs) para tomar decisões, direcionar processos ou gerar respostas, e precisam de acesso governado a sistemas e dados.

Construímos integrações críticas, responsáveis por garantir que pagamentos, pedidos e solicitações de indenização não se percam pelo caminho. Antes de permitir que um modelo construísse ou gerenciasse uma dessas integrações, ele precisava conquistar nossa confiança. Veja como chegamos até aqui e o que está funcionando até agora.

O que tentamos primeiro (e por que não funcionou)

Os fornecedores de modelos de base fizeram uma sugestão simples: dê um objetivo a um modelo com alta capacidade de raciocínio e veja o que ele produz. Pedimos a um agente genérico de programação que integrasse nossos sistemas.

O agente produziu um workflow que compilava corretamente. Também escreveu seus próprios testes, e todos passaram. Mesmo assim, não teríamos colocado aquele workflow em produção. Testes escritos pelo próprio agente que desenvolveu a solução tendem a validar suas próprias premissas. Sem analisar cada linha de código, não tínhamos como saber o que havia ficado de fora. Reconstruir tudo do zero teria sido mais rápido do que entender o resultado gerado.

Esses experimentos também deixaram claro que o código puro não era o meio adequado para trabalhar com integrações. Quando precisa construir tudo do zero, um agente genérico de programação tem que descobrir, a cada execução, como se comunicar com sistemas críticos. A Digibee já oferece conectores que enviam mensagens SOAP para sistemas legados e fazem chamadas a APIs modernas. Disponibilizamos esses conectores prontos para o agente. Isso resolveu a forma como ele se comunicava com os sistemas corporativos. Mas não resolveu como ele projetava as integrações.

Toda integração envolve uma série de decisões. Onde um processo deve se dividir? O que constitui uma unidade de trabalho? O que acontece quando algo falha no meio da execução? Decisões equivocadas podem duplicar pedidos ou fazer transações se perderem. Sem uma especificação, o agente tomava todas essas decisões silenciosamente, sem registrar as justificativas e sem que houvesse alguém responsável por elas. O workflow também não seguia uma organização que uma pessoa normalmente adotaria. Até poderia funcionar, mas era difícil de entender e ainda mais difícil de manter.

Por isso, estabelecemos uma regra: toda decisão precisa ter um responsável identificado e uma justificativa documentada antes da construção. Uma integração só pode entrar em produção quando seu responsável consegue explicar como ela funciona e por quê.

Um copiloto não era suficiente

Permitir que um agente tomasse todas as decisões não funcionou. Um engenheiro de integração poderia identificar as lacunas durante a revisão do workflow. Mas, naquele momento, corrigi-las exigia tanto retrabalho que o ganho obtido com a construção inicial praticamente desaparecia.

Então, incluímos uma pessoa no processo. Configuramos o agente de programação como um copiloto, um parceiro com quem poderíamos discutir ideias e refinar decisões. Passamos a definir essas decisões em conjunto. Isso elevou o nível do trabalho do engenheiro, que deixou de se concentrar diretamente nas integrações para trabalhar nas decisões que orientam sua construção. Em vez de um único prompt extenso seguido de uma grande entrega, refinávamos o contexto gradualmente até chegar a uma especificação. Primeiro, revisávamos as decisões documentadas. Depois, verificávamos se os workflows gerados estavam alinhados a elas. Essa foi nossa resposta à segunda pergunta: o código não é o nível adequado de abstração. As decisões são.

Pela primeira vez, essa abordagem reduziu a carga de trabalho do engenheiro de integração. Mas ainda não era suficiente. Duas perguntas continuavam surgindo. Como fazer a IA produzir boas recomendações e propostas? Como saber se a especificação contém tudo o que é necessário para construir a integração? Mantivemos o agente de programação e o copiloto. Precisávamos de algo além deles.

Ensinando integração ao sistema, não apenas programação

O problema não era a capacidade de raciocínio. O modelo já tinha conhecimento em escala de internet incorporado aos seus parâmetros. O que faltava era raciocinar sobre os aspectos que um arquiteto de integração consideraria. Por isso, ensinamos integração ao modelo adicionando três elementos à sua capacidade de raciocínio: um operador, um método e um Harness. O resultado é o que chamamos de Digibee Digital Workers.

O operador é um agente especializado, com profundo conhecimento em integração. Ele sabe como deve ser uma boa integração porque fornecemos diretrizes de construção para 13 arquétipos diferentes. Também conhece as decisões exigidas por cada tipo de integração, porque organizamos as opções e seus respectivos trade-offs por arquétipo. Integrações em tempo real, por exemplo, exigem um conjunto de decisões. Integrações em lote exigem outro. Integrações orientadas a eventos apresentam um terceiro conjunto.

O Harness é o ambiente que envolve o modelo: mecanismos de proteção, validação, ferramentas e recursos para preservar o contexto de uma etapa para outra. Ele mantém o Digital Worker dentro dos limites estabelecidos. A validação acontece de duas maneiras. Um modelo verifica o significado das respostas com base em critérios definidos. O código verifica aquilo que pode ser testado de forma objetiva.

O método define como uma pessoa e a IA trabalham juntas. Um Digital Worker conduz uma entrevista com você. Ele executa um playbook, uma sequência de etapas orientadas a um resultado definido, e aciona skills que estruturam decisões e apresentam alternativas. Uma skill leva à próxima, mas você também pode voltar às etapas anteriores.

Como parte dessa estrutura, criamos skills, instruções reutilizáveis que o Digital Worker carrega para executar determinada tarefa, para ajudar os usuários a definir a topologia e o design das integrações. Isso fez com que a estrutura gerada deixasse de ser uma surpresa. Se você pedir um círculo, pode receber variações de tamanho ou cor, mas não vai receber um dinossauro.

O que conseguimos na prática

Essa combinação nos permitiu criar uma integração pronta para entrar em produção. E vale enfatizar: pronta para produção. Um Digital Worker nos entrevistou para identificar exceções de negócio, erros técnicos e requisitos de transformação. A especificação resultante contemplava tudo o que era necessário para a construção. Registramos e aprovamos cada decisão arquitetural.

Quando os workflows ficaram prontos, conseguimos verificar se a IA havia seguido essas decisões. Quando ela interpretava algo incorretamente, podíamos corrigir o problema da mesma forma que faríamos com um novo colega de trabalho: por meio de perguntas, respostas e esclarecimentos.

O operador também questiona decisões. Em um projeto, nosso Field CTO definiu uma arquitetura para uma integração planejada. Seu Digital Worker questionou a escolha: os requisitos apresentados correspondiam a um arquétipo diferente daquele selecionado inicialmente. O agente perguntou se ele gostaria de reconsiderar. Ele reconsiderou.

É o conhecimento especializado cumprindo seu papel.

Rediscutindo as mesmas decisões

Boas especificações nos permitiram construir integrações prontas para produção, mas identificamos outro problema: repetíamos as mesmas decisões a cada novo projeto. Os Digital Workers conheciam o funcionamento das integrações de maneira geral, mas não sabiam nada sobre as escolhas que já havíamos feito em determinado ambiente.

A solução foi criar uma memória organizacional: um espaço onde o Digital Worker armazena decisões anteriores e as consulta nos projetos seguintes. Essa memória preserva preferências, padrões de segurança e diretrizes de arquitetura. Quando um workflow precisa de uma fila, por exemplo, o Digital Worker já sabe qual utilizar, sem precisar perguntar novamente.

As decisões existem em diferentes níveis. Algumas pertencem a um único projeto. Outras se aplicam a programas que duram vários anos. As mais abrangentes se aplicam a todo o ambiente corporativo: princípios, arquitetura e localização dos sistemas de registro oficiais (systems of record). Como essas decisões ficam centralizadas, um Digital Worker também consegue realizar análises de impacto. Se você estiver transferindo os dados mestres de clientes do ERP para o CRM, por exemplo, ele pode identificar quais workflows precisarão mudar e quais alterações serão necessárias.

Onde ficam os objetivos agora

Os objetivos continuam sendo definidos por pessoas: qual resultado você precisa alcançar, não como construí-lo. A partir daí, um Digital Worker atua em 13 disciplinas, incluindo arquitetura corporativa, arquitetura de integração, gestão da qualidade e análise de negócios. Cada disciplina possui objetivos próprios e resultados verificáveis, incorporados às instruções que orientam sua execução. São disciplinas, não cargos. Um Digital Worker participa de uma disciplina como integrante da equipe, sem substituir o profissional responsável por ela.

Nossos Digital Workers apresentam alternativas e trade-offs, sem assumir que uma das opções esteja correta por padrão: processamento síncrono ou assíncrono, sistemas fortemente ou fracamente acoplados, consistência estrita ou eventual. Os requisitos determinam a escolha. Um banco tende a priorizar uma arquitetura Zero Trust. Uma plataforma de e-commerce pode otimizar a velocidade das transações. Qualquer decisão irreversível ou com potencial de impacto abrangente precisa passar pela aprovação de uma pessoa.

Criação colaborativa e delegação

Nossa abordagem com Digital Workers muda a forma como as pessoas distribuem seu tempo. Você desenvolve o design e o planejamento em conjunto com a IA. Depois, delega as tarefas de maior volume. Os Digital Workers constroem versões iniciais dos workflows e monitoram aqueles que já estão em produção. Eles encaminham decisões para validação pela equipe. A decisão final continua nas mãos de uma pessoa responsável e identificada. Uma boa conversa com o Digital Worker traz dois benefícios: a especificação e os workflows alcançam um padrão de qualidade mais elevado, e você se torna um profissional de integração mais preparado.

Mas essa abordagem também tem custos. A velocidade desloca o gargalo. Quando o trabalho de design passa de dias para horas, a revisão humana se torna o fator que determina o ritmo das entregas. A especificação também precisa ter o nível adequado de detalhamento. Detalhes demais fazem o engenheiro passar o dia supervisionando a IA. Detalhes de menos fazem a IA seguir na direção errada, construir workflows inadequados e desperdiçar tokens. Nossa própria equipe de serviços profissionais encontrou dificuldades para aprender os novos processos de revisão, mas vários integrantes já obtiveram resultados expressivos.

Uma de nossas engenheiras de serviços profissionais havia previsto 12 dias para analisar dados, projetar a arquitetura e refinar os requisitos de negócio de um projeto. Com um Digibee Digital Worker, ela concluiu esse trabalho em aproximadamente três horas, cerca de 32 vezes mais rápido, e 9 dos 11 fluxos do projeto estavam prontos para a etapa de construção. Esse ganho corresponde a uma fase específica do ciclo de vida da integração. E um único projeto não representa todo um backlog, mas significa uma demanda concluída, abrindo espaço para a próxima.

Encontrando o equilíbrio certo

Forneça contexto demais à IA e a qualidade começa a cair. Forneça contexto de menos e você perde a capacidade de orientar o resultado. Existe um equilíbrio entre controlar cada detalhe e não oferecer orientação alguma. Incorporamos esse equilíbrio ao Harness e ao operador. Também estamos trabalhando para representar as skills e as especificações como grafos, mapas que mostram como cada elemento se conecta aos demais. Assim, a IA poderia percorrer essas conexões e mostrar os requisitos relevantes e os impactos de cada decisão no momento em que ela é tomada.

Nossa confiança nos Digital Workers se baseia em três pontos:

• Confiamos nos conectores testados que o Digital Worker utiliza para construir integrações.

• Confiamos no conhecimento especializado em integração incorporado ao Digital Worker.

• Podemos verificar o trabalho do Digital Worker com base na especificação que desenvolvemos em conjunto.

Se eu pudesse investir em apenas uma parte desse modelo operacional, investiria no trabalho que acontece antes da construção: o desenvolvimento colaborativo da especificação e a engenharia de contexto na memória organizacional. Ambos elevam o padrão de qualidade antes mesmo que alguém precise revisar um workflow.

Tenha acesso antecipado à primeira plataforma de integração AI-native →