Governança de IA sai do colo da TI e vira decisão de negócio

Uma discussão captada ao vivo pela redação do iMasters no palco Plenária Tecnologia & Inovação do Fórum E-Commerce↳E-commerce21 conteúdosECBR Club: novo espaço para devs se conectarem ao ecossistema de e-commerceDev (Back & Front) · mai 2025TOTVS anuncia joint venture com VTEXMarketing Tech · mai 2019Jovens da Brasilândia recebem formação gratuita em tecnologiaGestão Dev & TI · jul 2025Ver tudo em Marketing Tech → Brasil 2026 tocou num ponto que já não dá para fingir que é só técnico: quando a IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → deixa de ser projeto de TI e passa a ser prioridade de negócio, quem decide, quem entrega e quem responde muda de figura. A transcrição é automática (nomes, números e siglas podem ter erro de reconhecimento), então trato aqui as ideias, não atribuições a pessoas específicas.

O ganho de produtividade vira orçamento

O fio mais concreto do debate foi o uso do ganho de produtividade em engenharia como moeda para atacar débito técnico. Um dos participantes descreveu um sistema legado de loja que "tinha mod, tem mod", código que "gente não tem nem coragem de mexer", e que a reescrita estimada em dois anos passou a caber em seis meses. A frase que resume a mecânica: "Estou usando o meu dinheiro de produtividade."

É um enquadramento interessante e vale um filtro cético. Ganho de produtividade em desenvolvimento com IA é real em tarefas específicas, mas os números soltos no palco (40, 50, 60%) são autoavaliações, não benchmark controlado. O próprio palestrante fez a ressalva honesta: o ganho está no time de desenvolvimento, não na cadeia inteira. Ninguém consegue dizer que marketing ficou 50% mais rápido. Essa distinção importa muito para quem constrói: produtividade de código não se propaga automaticamente para o resultado de negócio, e reinvestir esse ganho em débito técnico é uma escolha de alocação, não um efeito colateral gratuito.

Outros exemplos citados seguem a mesma lógica de internalizar o que antes era comprado: cancelamento de um contrato de teste automatizado com a plataforma reconstruída internamente, esferas de DevOps↳DevOps29 conteúdosHabilite o Código de Segurança Azure DevOpsDevSecOps · jun 2025O que é DevOps – minha experiência como executivo nessa frenteDev (Back & Front) · abr 2026DevOps: a automação de processos de TI como estratégia de eficiência operacionalDev (Back & Front) · set 2024Ver tudo em DevSecOps → automatizadas e um time de cybersecurity que largou um sistema de gestão de vulnerabilidades de prateleira para construir a priorização de correções com IA. O padrão aqui é claro: build sobre buy quando o custo marginal de construir cai. O trade-off que a plenária não detalhou é o de manutenção. Plataforma interna vira dívida futura se não houver time para sustentá-la.

O modelo operacional: nem TI mandando, nem negócio esperando

O centro do debate foi a governança. A provocação do mediador foi direta: qual modelo de responsabilização faz a mudança acontecer junto das áreas de negócio, ou a tecnologia ainda tem protagonismo total?

A resposta rejeitou os dois extremos. Segundo um dos participantes, o momento atual é disfuncional: "a TI tem que ir ao negócio demandar e o negócio está esperando a TI". Ou seja, cada lado espera o outro puxar. A proposta foi trabalhar "de forma única", sem essa polarização, criando eficiência de entrega e produzindo mais internamente.

Houve também uma observação empírica relevante, atribuída a inspeções e diagnósticos de mercado: empresas de segmentos semelhantes, usando tecnologias semelhantes, chegam a resultados "absolutamente diferentes". Se a ferramenta é a mesma e o resultado varia, a variável decisiva não é o modelo nem a stack, é o modelo operacional e a maturidade organizacional. Esse é o recado prático para quem lidera engenharia: comprar o mesmo LLM que o concorrente não gera vantagem por si só.

Um sinal citado de que a decisão migrou de área: a apresentação de uma jornada de IA feita por CIO e CFO juntos no palco. E a constatação de que a compra de tecnologia hoje é feita "diretamente pelas áreas de negócio", diferente de eras anteriores em que a decisão ficava "blindada dentro da tecnologia". Isso redefine o papel de quem lidera tecnologia: menos dono da decisão, mais orquestrador que precisa garantir que a entrega distribuída não vire caos de governança.

A pergunta que fica em aberto: quem responde pelo agente?

O fecho mais provocativo foi sobre responsabilização. A proposta foi "criar uma trilha que possa governar esse caminho" e "construir tecnologia com responsabilidade". E aí a pergunta que ninguém respondeu no palco, e que vale levar para dentro da sua organização: em um cenário com gerente, coordenador e um agente de IA no mesmo fluxo, "quem responde pelo agente de IA? É a área de tecnologia?"

Para quem constrói agentes hoje, isso não é filosofia. É a diferença entre um agente que executa ações com efeito real (aprovar, comprar, escrever no banco de produção) e um humano nomeado como responsável por aquele escopo. Definir accountability antes de dar autonomia ao agente é o item que costuma ficar de fora do roadmap e que aparece caro quando algo quebra. A plenária não entregou o modelo pronto, mas colocou a pergunta certa na mesa.

Fonte: Transcrição ao vivo — Plenária Tecnologia & Inovação (12:00–12:30)