O décimo deploy não se redesenha: agentes de várias plataformas operando como um só sistema governado

O problema mudou: de fazer funcionar para operar

Agentes de IA já entregam resultado. Em muitas empresas, um agente que reconcilia pedidos, sugere reposição ou prepara uma análise de crédito deixou de ser novidade. A dificuldade agora é outra: operar esses agentes, todos os dias, em escala e sob governança.

E eles não chegam por um só caminho. Vêm embutidos no ERP, no CRM, na plataforma de dados, no BI, nas ferramentas de produtividade e nos sistemas que o próprio time constrói. Cada plataforma traz seu console, suas permissões, seus registros e sua regra de aprovação.

Chamamos de décima implantação a décima vez que o mesmo uso de agentes precisa rodar num lugar novo: outra unidade de negócio, outro país, outro ERP, outra plataforma. É ali que a escala é testada de verdade. Escalar, então, não é só levar um caso para a segunda unidade. É repetir a operação em cada unidade e em cada plataforma, com outro ERP, outro regulador e um gestor que não participou do desenho inicial. Sem uma governança comum, cada combinação vira um projeto novo.

As três perguntas certas, respondidas no lugar errado

Há um consenso saudável sobre o que perguntar desde o primeiro dia:

• O dado que o agente usa é confiável fora do contexto em que foi preparado?
• Onde decide a pessoa e onde decide a máquina?
• Quem responde pela operação depois de entrar em produção, com qual orçamento e custo?

As perguntas estão certas. O problema é onde as respostas ficam. Parte delas está em documentos de arquitetura, matrizes de responsabilidade e decisões de comitê. A outra parte está espalhada pelas plataformas: cada uma responde do seu jeito, com seus próprios papéis, limites e trilhas. Ninguém enxerga o conjunto.

Quando uma regra que deveria valer em cada ação depende da memória do time ou da configuração de cada plataforma, ela não sobrevive à troca de pessoas, à pressão de prazo e à próxima unidade.

Uma linha desenhada no quadro branco não sobrevive à segunda implantação. Ela precisa estar no próprio sistema.

A tese deste artigo é direta: escala é propriedade de uma operação governada. Um plano de controle acima das plataformas, com controles executáveis, responsabilidade fiduciária explícita e recursos para sustentar a operação. Cada uma das três perguntas tem uma resposta que pode ser executada, e não apenas declarada.

1. Dado: fica no seu stack, e só entra na decisão o que foi admitido

O caminho que adotamos separa dois planos:

• Plano de dados: ERP, data warehouse, lakehouse, BI e plataformas como Snowflake, Databricks ou Fabric. Ele fica no ambiente do cliente; não exigimos substituí-lo como condição de partida.
• Plano de controle: decisão, mandato, verificações de autorização e registro do ato. É ele que se repete igual em cada implantação e sobre cada plataforma.

A separação não elimina o trabalho de integração. Duas unidades, ou duas plataformas, podem usar o mesmo nome para métricas diferentes: “margem” pode incluir frete numa e excluí-lo na outra. Uma conexão funcionando não resolve essa diferença.

Por isso o dado não vira contexto de decisão só porque chegou. Ele é admitido, com critérios explícitos: origem, significado, atualização, qualidade, permissão de uso e responsável. E a admissão vale para uma finalidade: um dado adequado para previsão comercial pode ser insuficiente para liberar um pagamento. O mesmo vale para o que um agente de plataforma produz: é um candidato até ser admitido.

2. Decisão: a pessoa autoriza o mandato, o agente atua dentro dele

A fronteira entre pessoa e máquina não é uma linha única para a solução inteira, nem uma configuração diferente em cada plataforma. Ela vale por ação, conforme o risco do ato. Ler um relatório, alterar um preço e liberar um pagamento exigem controles diferentes.

Autorização e execução têm papéis distintos:

• A pessoa autoriza o mandato. Quem tem alçada define as ações permitidas, os limites, a validade e as condições de suspensão.
• O agente atua dentro do mandato. Ações elegíveis são executadas quando a política autorizada permite. O agente nunca aprova a própria proposta nem amplia a própria alçada.
• Agentes de plataformas e de terceiros propõem. O que eles sugerem passa pelo mesmo mandato, pela mesma verificação e pelo mesmo recibo que os agentes próprios. A plataforma muda; a regra, não.
• Exceções exigem nova decisão. Ações fora dos limites, ou que exigem aprovação individual por política ou regulação, vão para uma pessoa autorizada antes de executar.
• Limites financeiros são verificados no ato, a cada chamada. Fora do envelope de valor, a ação vira proposta; não é executada.

A autonomia é conquistada por evidência: execuções, tempo de observação, resultados, erros, incidentes e qualidade das revisões. Uma taxa alta de aprovação, isoladamente, não basta. Quando os critérios são violados, a autonomia é reduzida ou suspensa automaticamente. Só uma pessoa autorizada a restaura.

Assim, a linha não depende de alguém lembrar dela nem de cada plataforma configurá-la igual. Ela é aplicada no momento do ato, na décima implantação como na primeira.

A governança humana também precisa de prova

Colocar uma pessoa no circuito não garante revisão. Com agentes de várias plataformas pedindo aprovação ao mesmo tempo, um aprovador sob pressão pode seguir a recomendação da máquina sem examiná-la, especialmente quando recebe mais pedidos do que consegue avaliar.

A literatura conhece esse risco há décadas. Bainbridge discutiu as “ironias da automação”, incluindo a dificuldade de manter pessoas preparadas para intervir em processos altamente automatizados [1]. Parasuraman e Manzey analisaram a complacência e o viés de automação [2]. Elish mostrou como a responsabilidade pode recair sobre quem tem pouco controle real [3]. O Regulamento Europeu de IA pede, na supervisão de sistemas de alto risco, consciência sobre esse viés [4].

Por isso, no nosso desenho, a revisão humana também é avaliada. Aprovar sem abrir a evidência não conta como revisão. Abrir também não basta: abrir um documento não prova compreensão, e aprovar rápido não prova, por si só, negligência. Acesso à evidência e tempo de revisão são sinais, combinados com revisão amostral, erros encontrados, resultados posteriores e a capacidade de contestar ou interromper a execução.

Os indicadores são agregados por fluxo, faixa de risco e time, e nunca viram ranking de pessoas. Servem para ajustar processo e carga de trabalho, não para vigiar quem julga.

Soberania cognitiva: o que os agentes aprendem é da organização

Com agentes em várias plataformas, não são só as regras que se dispersam. O aprendizado também. Cada agente acumula contexto, correções, exceções tratadas e o jeito de trabalhar da organização. Se esse aprendizado fica dentro do modelo ou do ambiente de cada fornecedor, o conhecimento da própria operação acaba espalhado por várias plataformas, sem curadoria e sem como acompanhar a empresa quando ela troca de ferramenta.

O mercado começa a chamar isso de soberania cognitiva: manter o controle sobre o que a IA aprende com a organização e sobre o próprio juízo. Como escreveu Bramley Maetsa, executivo de TI da Sasol, sobre a empresa que adota IA: “seus dados podem ser soberanos; seu aprendizado pode não ser” [5].

Ela tem duas faces, e as duas são condição de escala:

• O aprendizado é da organização. Memória, conhecimento e habilidades dos agentes ficam no ambiente da organização, com curadoria humana, autor e histórico, fora do modelo do fornecedor. Uma lição só entra depois de aprovada por uma pessoa. O que um agente aprende numa unidade pode servir a outra, porque pertence à organização, e não a uma plataforma.
• O juízo é das pessoas. É o que as seções anteriores descrevem: mandato humano, revisão avaliada e capacidade de contestar ou interromper a execução.

Sem a primeira face, cada nova plataforma recomeça do zero. Sem a segunda, a organização escala carimbos. Detalhamos as duas na Planta de Governança.

3. Responsabilidade fiduciária: delegar execução não é delegar responsabilidade

“Quem responde depois de entrar em produção” costuma ser respondido com um nome, uma linha de orçamento e um custo de operação. É necessário, mas não basta. Um agente age em nome da organização, e a organização age em nome de clientes, acionistas e reguladores. A pergunta de fundo é fiduciária: quem conferiu autoridade a quem, para qual finalidade, até quando, e quem responde pelo que foi feito com ela.

Com agentes espalhados por várias plataformas, essa cadeia costuma se partir. Cada plataforma registra quem configurou o agente, não quem responde por ele. Por isso, no nosso desenho, a responsabilidade é um instrumento, e não um nome numa apresentação:

• Mandato aceito, não apenas concedido. O mandato nasce pendente e só passa a valer com o aceite nominal de quem responde. Conceder não é assinar. Ele declara finalidade, ações, objetos, limite de orçamento e vigência.
• Segregação de funções. Quem pede, quem aprova e quem executa são papéis distintos conforme o risco. Onde a política exige, a atestação é feita por outra pessoa, diferente de quem decidiu.
• Recertificação e renovação. A autoridade é revista por prazo ou por mudança, e o mandato só é renovado por pedido registrado. Nenhum agente nasce sem dono, domínio e vínculo.
• Orçamento e custo recorrente: integração, infraestrutura, consumo de modelos em cada plataforma, revisão humana, suporte e manutenção.
• Capacidade operacional: atendimento a incidentes, treinamento e tempo disponível para revisão.
• Recibo por ato: ação, agente, plataforma de origem, mandato, autorização, evidência utilizada e resultado observado, no mesmo formato para todas as plataformas.

O recibo reconstrói o que aconteceu e sustenta auditoria e investigação. Ele não demonstra sozinho que uma ação causou um ganho financeiro: a leitura de valor precisa de referência de comparação, custo completo e método de atribuição adequado ao caso. Repetir uma execução técnica com custo superior ao benefício não é escala; é desperdício replicado.

Governança que se evidencia, não que se declara

Política de IA aprovada em comitê é ponto de partida. O que conselho, auditoria e regulador vão pedir é evidência. Uma operação governada responde, para qualquer ato de qualquer agente, em qualquer plataforma:

• Quem agiu: a pessoa ou o agente, com a plataforma de origem e o autor real.
• Sob qual autoridade: o mandato vigente, quem o aceitou e qual alçada se aplicava.
• Com qual evidência: o contexto admitido, a recomendação e a revisão humana.
• Com qual efeito: o resultado observado e o domínio afetado.
• O que foi negado: a tentativa fora do mandato, bloqueada antes de executar, também deixa registro.

Essa trilha pode ser consultada por pessoa, por agente e por decisão. Correções de autoria são registradas sem apagar o original. A exportação para auditoria é encadeada por hash, para que um corte ou uma alteração fiquem visíveis. A mesma trilha se liga às referências que o mercado já cobra, como o EU AI Act, a LGPD, a ISO/IEC 42001 e o NIST AI RMF [6][7], sem substituir parecer jurídico nem certificação.

É isso que permite escalar sem diluir a responsabilidade: a décima implantação responde às mesmas perguntas, com a mesma qualidade de evidência, que a primeira. Mostramos esse mapa na Planta de Governança.

O décimo deploy não se redesenha. Se compõe.

A composição em camadas delimita o que se reutiliza e o que se adapta:

• Núcleo: decisão, mandato, verificação e registro. O mesmo em todas as implantações e plataformas.
• Setor: cookbooks setoriais com receitas de ponta a ponta, da fonte ao valor capturado: fluxos, conceitos e controles próprios do domínio.
• Mercado: exigências regulatórias e práticas locais.
• Cliente: plataformas, integrações, responsabilidades, limiares e escolhas da organização.

Um exemplo ilustrativo: reposição de estoque em duas unidades. Na primeira, a sugestão vem de um agente na plataforma de dados; na segunda, de um agente embutido no ERP. O registro de autorização e a verificação de limites vêm prontos do núcleo. A receita de reposição vem do cookbook do setor. Na segunda unidade, o trabalho é local e explícito: mapear outro ERP, validar unidades de medida, prazos de fornecedores e regras de compra. Se a política local exigir dupla aprovação, ela entra como configuração do mandato, não como redesenho.

A separação entre núcleo e setor tem um teste simples: se algo precisa ser reescrito para o segundo setor, ou para a segunda plataforma, estava no lugar errado. E cada implantação devolve aprendizado ao núcleo e ao cookbook.

O décimo deploy não se redesenha. Se compõe: mesmo núcleo, outra configuração, resultado validado de novo.

Cada nova implantação produz evidência

Escala se afirma com medida, não com slide. Antes de cada nova unidade ou plataforma, definimos os critérios de sucesso e medimos:

• o esforço de integração e adaptação;
• o que foi reutilizado e o que exigiu mudança;
• como variaram erros, incidentes e carga de revisão humana;
• o custo total de operação e o resultado de negócio;
• se a equipe local opera e responde a desvios sem depender de quem fez a primeira implantação.

Essas medidas separam reutilização real de trabalho específico escondido sob uma configuração. Também mostram cedo quando uma nova unidade exige um investimento que o caso de negócio não sustenta.

O que fica para a liderança

Desenhar cedo para a escala continua essencial. Mas arquitetura sem operação não é suficiente: é narrativa. Um diagrama de camadas, um framework com nome próprio e um RACI bem desenhado descrevem a intenção; não aplicam o mandato no momento do ato, não negam a ação fora do limite, não medem a revisão humana nem deixam recibo. A escala só existe quando a arquitetura vira operação, executada todos os dias e verificável por quem precisa responder por ela.

Arquitetura sem operação é narrativa. Escala é arquitetura em operação, com evidência.

A diferença está em onde ficam as respostas. Se ficam em documentos, na memória do time e na configuração de cada plataforma, a escala depende da memória de quem desenhou, e essa memória se dilui a cada nova unidade e a cada novo agente. O que escala é uma disciplina de operação, executada todos os dias dentro de uma operação governada. Se ficam numa operação governada acima das plataformas, com mandato aceito, dono com orçamento, evidência auditável e um aprendizado que pertence à organização, a escala passa a ser uma propriedade do sistema.

Uma pergunta ajuda a separar uma coisa da outra:

Na sua operação de agentes, qual regra ainda depende de alguém lembrar dela, ou de cada plataforma configurá-la igual?

Fundamentos e leituras

1. Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775–779. Contribuição: mostra por que a automação crescente dificulta a intervenção humana quando ela é necessária. Limite: estudo de controle de processos industriais, anterior à IA generativa.
2. Parasuraman, R.; Manzey, D. H. (2010). Complacency and bias in human use of automation: an attentional integration. Human Factors, 52(3), 381–410. Contribuição: define complacência e viés de automação e suas causas atencionais. Limite: baseado sobretudo em experimentos de laboratório e em aviação.
3. Elish, M. C. (2019). Moral crumple zones: cautionary tales in human-robot interaction. Engaging Science, Technology, and Society, 5, 40–60. Contribuição: descreve como a responsabilidade recai sobre a pessoa com menos controle real. Limite: análise de casos, não medição quantitativa.
4. Regulamento (UE) 2024/1689 (AI Act), Art. 14, n.º 4, alínea b). Contribuição: exige que a supervisão humana de sistemas de alto risco considere o viés de automação. Limite: aplica-se a sistemas de alto risco na União Europeia; não é norma brasileira.
5. Maetsa, B. (2026, 28 set.). Learning sovereignty: AI’s next enterprise battle. ITWeb. itweb.co.za. Contribuição: nomeia o risco de o aprendizado corporativo ficar com o fornecedor de IA. Limite: artigo de opinião de executivo de TI em veículo setorial, sem dados empíricos; citação em tradução livre.
6. ISO/IEC 42001:2023. Information technology — Artificial intelligence — Management system. International Organization for Standardization. Contribuição: estrutura um sistema de gestão de IA com papéis, responsabilidades, controles e melhoria contínua. Limite: norma de sistema de gestão; a menção não indica certificação.
7. National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1. Contribuição: organiza a gestão de risco de IA nas funções governar, mapear, medir e gerenciar, com ênfase em responsabilização. Limite: referencial voluntário dos EUA; não é norma brasileira.