Pense em uma empresa como uma cidade. Negócio é o plano diretor (“onde queremos crescer”), arquitetura são as ruas e regras de tráfego (“como as coisas se conectam”), tecnologia é o asfalto, os semáforos e os veículos (“o que realmente roda”), e stakeholders são as pessoas que vivem ali e sentem o efeito de tudo isso.
GeoIT parte de uma ideia simples: se você muda o “motor” da cidade (IA + automação), não basta checar um mapa bonito — precisa checar se o circuito continua fechando: Stakeholders → Negócios → Arquitetura → Tecnologia → Stakeholders.
E aqui entra o CoE (Círculo de Equivalência): é como desenhar uma sala com regras antes de discutir “mudança”. Dentro dessa sala, você fixa escopo, janela de tempo, jurisdição e configuração (modelos, integrações, políticas) e só então aceita que algo “continua sendo a mesma coisa para este propósito”. Se isso não se sustenta, não é “ajuste fino” — é caso de redesenhar a sala e registrar o que foi aceito.
Este post é um GeoIT Map: um diagnóstico para encontrar onde surgiram atalhos (efeitos chegando em stakeholders sem passar pelo negócio e pela arquitetura) e onde o sistema está virando “outra coisa” sem ninguém declarar que decidiu isso.
Círculo de equivalência do diagnóstico
- Escopo: agente/chatbot em canais digitais que negocia com clientes (desconto, retenção, reembolso, upgrade)
- Janela: 90 dias (antes/depois)
- Jurisdição/regime: Brasil (consumidor + LGPD, políticas internas)
- Configuração: modelo + prompt principal + ferramentas (CRM, preços, cupons, reembolso) + regras de limite + monitoramento
- Critério de equivalência: “ofertas e exceções só podem mudar dentro de limites aprovados e auditáveis, sem alterar a política comercial por inércia.”
AS-IS
Stakeholders
O cliente percebe “ajuda”, mas vive variação: um dia o bot concede desconto alto, outro dia recusa. Vendas sente conflito com o playbook. Financeiro percebe margem caindo “sem campanha”. Risco/compliance percebe concessões sem critério consistente e sem explicação operacional clara. Isso é um sinal clássico de descolamento: a experiência real dos stakeholders está se afastando do que o negócio acha que está fazendo.
Sinais típicos
- exceção vira rotina (“foi só desta vez” repetido)
- reclamações de inconsistência (“para mim foi X, para outro foi Y”)
- atrito interno entre canais (“o bot atropela regras”)
- o problema só aparece quando a conta já chegou (margem, churn, reputação)
Negócios
A promessa vira “aumentar conversão e reduzir custo”. O incentivo real vira “fechar mais” e “resolver rápido”. Só que isso pode criar um caminho onde o sistema, na prática, resegmenta clientes e reescreve política comercial sem que isso tenha sido assumido como decisão de negócio.
Arquitetura
O bot tem acesso a ferramentas que “finalizam” coisas: aplicar cupom, trocar plano, conceder crédito, disparar reembolso. Sugestão vira execução porque está no caminho do atendimento. A política comercial existe em documento, mas não existe como componente executável que limite o que pode acontecer.
Sinais típicos
- permissões amplas em APIs (desconto/reembolso) sem corredor por risco
- ausência de “pontos de hesitação” (caso ambíguo vira decisão mesmo assim)
- exceções sem dono e sem expiração
Tecnologia
A plataforma registra conversas, mas não registra decisão de forma útil: o que foi concedido, por qual motivo, sob qual regra, com qual limite. Sem isso, a organização enxerga o efeito (margem caiu), mas não consegue explicar o mecanismo (como decisões viraram execução).
Onde o loop rasga
- Tecnologia → Stakeholders direto (atalho)
Como aparece: o bot muda o padrão de concessões e muda a experiência do cliente.
Por que é perigoso: política muda sem “quem decidiu” e sem limites claros.
O que faltou: limites executáveis + trilha mínima da concessão. - Negócios → Tecnologia sem passar por Arquitetura
Como aparece: “melhorar conversão” vira instrução e o sistema ganha autonomia operacional.
Por que é perigoso: objetivo vira comando; risco vira externalidade.
O que faltou: corredor de permissão + pontos de hesitação + critérios de escalonamento. - Arquitetura vira exceção permanente
Como aparece: um override temporário vira prática estável.
Por que é perigoso: exceção vira produto; produto vira risco.
O que faltou: dono, motivo, expiração e isolamento da exceção.
TO-BE
Stakeholders
O cliente ganha previsibilidade: oferta dentro de faixa clara, ou explicação simples + rota de escalonamento. Vendas e suporte ganham consistência: o bot executa o playbook dentro de limites, não “inventa campanha”.
Mudanças-chave
- contestação e escalonamento com critérios claros
- medição por segmento (onde o sistema concede mais e por quê)
- feedback estruturado para ajustar política sem guerra interna
Negócios
A tese muda de “resolver mais” para “resolver com controle”. Métricas passam a incluir o custo da cauda: exceções, reversões, margem por segmento, precedentes gerados.
Mudanças-chave
- metas com limites (conversão com teto de concessão e teto de exceção)
- orçamento de flexibilidade (quanta “folga” existe e onde)
- gatilhos de pausa: quando indicadores desviam, autonomia reduz
Arquitetura
Define direitos de decisão: o bot pode recomendar sempre, mas só pode executar dentro de um corredor. Fora do corredor: hesita, coleta evidências, pede confirmação ou escala.
Mudanças-chave
- corredor por risco/impacto (desconto baixo automático; desconto alto exige aprovação)
- pontos sem retorno explícitos (reembolso total, cancelamento, alteração de preço)
- exceções com dono, motivo e expiração
Tecnologia
Passa a produzir trilhas simples e estruturadas: evento de decisão, evento de execução, limites aplicados, motivo e resultado. E passa a ter reversão operacional: reduzir autonomia, pausar ferramentas, reverter configurações.
Mudanças-chave
- evento “concessão aplicada” com campos mínimos (valor, regra, limite, autorização)
- segregação de credenciais por corredor e ambiente
- mecanismos de contenção (kill switch, step-down de autonomia, rollback)
Recibos de equivalência
Recibo 0 — o que foi fixado no CoE
Escopo, janela, jurisdição e configuração. Invariantes: o sistema não cria nova política comercial por inércia; opera dentro de faixas aprovadas; fora da faixa, hesita e escala.
Recibo 0 — como o loop fecha sem atalhos
Negócios define limites e métricas de cauda; Arquitetura implementa corredores e hesitação; Tecnologia registra e bloqueia execução fora do corredor; Stakeholders têm contestação prática. Quando isso não for mais verdadeiro, a mudança não é “ajuste”: é redesenho explícito do CoE.
Síntese
Quando a IA “muda o negócio”, quase nunca é um grande anúncio estratégico. É um acúmulo de microdecisões executadas rápido demais, com limites frouxos demais, abrindo atalhos no loop. A virada de jogo é fechar o circuito: alinhar stakeholders, transformar promessa de negócio em limites executáveis, arquitetar corredores de decisão e instrumentar tecnologia para registrar e conter impacto.
Duas perguntas para encerrar: quem está autorizado a mudar a política na prática — e como a organização percebe isso antes de virar prejuízo?
E qual decisão o sistema deve aprender a não tomar quando a confiança cai?