Quem decide qual modelo de IA a sua empresa usa? Por que a decisão mais cara da operação costuma não ter dono
Toda operação que usa IA toma quatro decisões de forma recorrente: qual modelo aciona cada tarefa, quanto contexto é enviado, quanto de autonomia o sistema tem para agir e o que fica retido depois. Em quase toda empresa, essas quatro decisões são tomadas dezenas de vezes por dia por quem está com prazo, sem que ninguém as reconheça como decisões. É por isso que política de uso de IA raramente muda comportamento: ela descreve o que deveria ser decidido sem estabelecer quem decide, com qual critério e quem aprova a exceção. Um modelo operacional de governança resolve isso antes de qualquer redação, atribuindo dono e alçada a cada uma das quatro, e distinguindo o que é decisão de rotina, o que é exceção que exige aprovação e o que é decisão de política que não cabe a quem executa.
O modelo mais avançado como padrão para tudo
Lucio Figueiredo Matias, Head of Operations da CSP Tech, descreve um comportamento que observa se repetir em várias equipes: alguém descobre um modelo novo e mais potente, e ele vira o padrão para tudo, da tarefa mais simples à mais crítica. A lógica parece sólida. Se é o melhor disponível, por que não usar sempre.
A observação dele desmonta a lógica com uma distinção simples: capacidade e adequação são coisas diferentes. Um modelo mais avançado costuma custar mais por token, responder mais devagar e, em boa parte das tarefas do dia a dia, não entregar ganho perceptível de qualidade em troca desse custo extra. Classificar um texto curto, resumir um documento simples ou gerar uma resposta padrão não exigem o mesmo poder de raciocínio que resolver um problema de arquitetura ou analisar uma base de código inteira. Nas palavras dele, adotar o modelo mínimo que resolve a tarefa não é abrir mão de qualidade, é parar de pagar por poder computacional que a tarefa nunca ia usar.
O que interessa aqui, porém, não é o mecanismo de roteamento, que já detalhamos em artigo próprio sobre governança de custo de tokens. É a pergunta com que ele encerra a reflexão, e que costuma provocar silêncio em reunião de diretoria: na sua equipe, quem decide qual modelo deve ser utilizado em cada tarefa?
A tese deste guia: a decisão mais cara da operação de IA é a que não tem dono. Enquanto ninguém responde pela escolha de modelo, de contexto, de autonomia e de retenção, essas quatro decisões continuam sendo tomadas por quem tem menos incentivo para considerar custo, risco e conformidade, que é justamente quem está sob prazo. Governança de IA não começa por política, começa por atribuir donos a decisões que já estão sendo tomadas todos os dias sem que ninguém saiba que são decisões.
As quatro decisões que já estão sendo tomadas
A tabela abaixo costuma provocar reconhecimento imediato, porque a coluna do meio descreve o estado real da maioria das operações.

Vale notar o padrão das duas últimas linhas: quando não há dono, o padrão da ferramenta decide. Isso não é neutro, porque o padrão do fornecedor é desenhado para conveniência de uso, não para o perfil de risco da sua empresa. Ausência de decisão é uma decisão, tomada por terceiros.
Por que “quem decide” precede “o que decidir”
A sequência intuitiva de um programa de governança é escrever a política primeiro e definir responsabilidades depois. Na prática, essa ordem produz documento que ninguém aplica, porque uma regra sem alçada não é regra, é sugestão. Quando não está claro quem aprova a exceção, a exceção simplesmente acontece.
Duas referências reforçam esse ponto por caminhos diferentes. Segundo o analista sênior do Gartner Nitish Tyagi, a disciplina de tokens não emergirá apenas da escolha do desenvolvedor, porque desenvolvedores tendem a otimizar por velocidade e conveniência em vez de eficiência de custo, e sem um modelo operacional de engenharia governado os custos podem escalar mais rápido que os ganhos de produtividade que a ferramenta deveria entregar. Do lado normativo, a ISO/IEC 42001:2023, primeira norma internacional de sistema de gestão de IA, dedica um de seus blocos de requisito justamente à liderança, exigindo comprometimento e a atribuição de responsabilidades de governança de IA. As duas apontam para o mesmo lugar: sem responsabilidade atribuída, não há sistema, há intenção.
Os três níveis de alçada que fazem a política funcionar
Um modelo operacional útil não centraliza tudo, porque centralizar tudo trava a operação e gera contorno. Ele separa o que pode ser decidido no fluxo do que precisa de aprovação e do que não cabe a quem executa.

O nível de exceção é o que separa modelo operacional que funciona de burocracia que as pessoas driblam. Ele também é onde a segurança encontra a economia: o OWASP recomenda, entre as mitigações para autonomia excessiva em aplicações com IA, a supervisão humana em operações de alto impacto. Traduzido para alçada, isso significa que ações críticas não deveriam depender de o executor lembrar de pedir aprovação, e sim de o fluxo exigi-la. Aprovação que depende de memória individual não é controle.
Onde a alçada deixa de ser organograma
O registro da decisão e da exceção (consultoria Jira)
Alçada só existe de verdade quando pedir, conceder e negar deixam rastro. Na prática, isso significa tratar a exceção como uma requisição de serviço, com solicitante, justificativa, aprovador, prazo de resposta e histórico, exatamente o modelo que áreas de negócio já usam para outros pedidos internos. E significa tratar a decisão de política como um item próprio, com dono, data de revisão e registro do que valia antes, para que a mudança de regra seja auditável. No Jira e no Jira Service Management, isso é configuração deliberada de tipos de item, campos, fluxo de aprovação e trilha de transições. É também a diferença entre responder e não responder quando alguém perguntar desde quando determinada regra vale e quem a aprovou.
A responsabilidade sobre o dado (governança de dados)
Duas das quatro decisões, o contexto enviado e o que fica retido, dependem de alguém responder pelo dado envolvido. Sem dono de domínio de dado nomeado, a pergunta sobre o que pode ser enviado a um modelo não tem a quem ser dirigida, e a resposta acaba sendo dada por omissão. Do lado da plataforma, a documentação da Databricks descreve o Unity Catalog como a camada unificada de governança para dados e IA, com controle de acesso, linhagem e auditoria centralizados, e as mesmas permissões valendo para pessoas, notebooks e modelos. Isso dá à responsabilidade um lugar onde ser exercida: quem responde pelo domínio define quem acessa, e o sistema registra quem acessou.
Como saber que a decisão não tem dono
Quatro perguntas costumam revelar o estado real em poucos minutos de reunião. Se alguma delas gera silêncio ou provoca troca de olhares entre áreas, a decisão correspondente não tem dono:
• Quem definiu que este tipo de tarefa usa este modelo, e quando isso foi revisado pela última vez? Se a resposta é que sempre foi assim, não houve decisão, houve inércia.
• O que uma pessoa faz quando precisa de uma exceção? Se a resposta é que ela pergunta a alguém no chat, não existe alçada, existe informalidade que não deixa rastro.
• Que tipo de ação exige aprovação humana antes de ser executada? Se a resposta depende do bom senso de quem opera, o controle não é do sistema.
• Quem responde por quanto tempo o histórico dessa ferramenta fica guardado? Se a resposta é que o fornecedor define, a decisão de retenção foi terceirizada sem discussão.
Por que isso é trabalho de consultoria e não de organograma: atribuir dono é a parte fácil e costuma ser feita em uma reunião. O que faz o modelo operacional sobreviver é o desenho do que acontece depois: o padrão que se aplica sozinho, o caminho de exceção que responde rápido o suficiente para não ser driblado, o registro que transforma decisão em evidência e a revisão que mantém a regra viva.
Isso atravessa arquitetura de IA, engenharia de dados e gestão do trabalho. A CSP Tech atua nas três, como especialistas Databricks na camada de dado governado, com consultoria Jira como Atlassian Gold Partner na camada de decisão registrada, e com 34 anos de operação de engenharia na definição dos padrões por tipo de tarefa.
Quando formalizar alçada é excesso
• Time pequeno com uso de baixo impacto. Quando poucas pessoas usam IA para tarefas sem dado sensível e sem ação automatizada, o acordo informal funciona e o custo de formalizar supera o risco evitado.
• Fase de exploração. Descobrir o que a ferramenta faz bem exige liberdade de tentativa. O erro é manter o regime de exploração depois que o uso virou dependência operacional.
• Antes de existir inventário do uso. Definir alçada para um uso que ninguém mapeou produz governança sobre o que se imagina, e não sobre o que acontece. Mapear vem primeiro.
Perguntas frequentes
Quem deve decidir qual modelo de IA usar em cada tarefa?
A decisão não deveria ser individual e repetida a cada uso. O desenho que funciona define, em nível de política e com dono nomeado, qual nível de modelo corresponde a cada tipo de tarefa, aplica esse padrão de forma automática na rotina e reserva para aprovação apenas os casos que fogem do padrão. Deixar a escolha para quem executa transfere uma decisão de custo e de risco para o ponto do processo com menos incentivo para considerá-los, que é quem está sob prazo.
O que é um modelo operacional de governança de IA?
É a definição de quem responde por cada decisão recorrente do uso de IA, com qual critério e por qual caminho a exceção é pedida e concedida. Ele separa três níveis: rotina, que segue padrão automático; exceção, que exige aprovação registrada com prazo de resposta; e política, que define os padrões e limites e cabe a um dono nomeado, com revisão periódica. É o que transforma uma política escrita em comportamento observável.
Por que política de uso de IA costuma não mudar comportamento?
Porque descreve o que deveria ser decidido sem estabelecer quem decide e quem aprova exceção. Regra sem alçada é sugestão, e quando não há caminho rápido e registrado para pedir exceção, a exceção acontece de qualquer forma, apenas sem deixar rastro. É também o que a ISO/IEC 42001 endereça ao exigir, no bloco de liderança, a atribuição de responsabilidades de governança de IA.
Como controlar autonomia de agentes sem travar a operação?
Classificando ações por impacto e exigindo aprovação humana apenas acima de determinado nível, com o restante seguindo automaticamente. O OWASP recomenda supervisão humana em operações de alto impacto entre as mitigações para autonomia excessiva. O ponto crítico é que a exigência precisa estar no fluxo, e não depender de o executor lembrar de pedir: aprovação que depende de memória individual não é controle.
Próximo passo
Se a pergunta que abre este artigo provocaria silêncio na sua próxima reunião de liderança, o ponto de partida não é redigir uma política. É mapear quais decisões já estão sendo tomadas todos os dias e a quem cada uma deveria pertencer. Solicite um diagnóstico de modelo operacional de IA com a CSP Tech e receba o mapa das quatro decisões no seu ambiente: quem as toma hoje, onde falta alçada, que caminho de exceção precisa existir e onde cada decisão passa a ficar registrada.
Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google, Anthropic e Semrush. Com contribuição de Lucio Figueiredo Matias, Head of Operations da CSP Tech, cuja observação sobre adequação e capacidade de modelos originou este artigo. Revisão técnica por especialistas de dados e Atlassian da CSP Tech (Atlassian Gold Partner, Microsoft Gold Partner, parceira Databricks, participante do Anthropic Partner Network, 34 anos de mercado).
Fontes (acesso ago/2026): Gartner, press release sobre consumo de tokens e custos de AI coding (gartner.com/en/newsroom, 24/jun/2026), quanto às declarações do analista sênior Nitish Tyagi sobre disciplina de tokens e modelo operacional de engenharia governado, mantidas como declaração atribuída. ISO, plataforma oficial de normas, ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system (iso.org/obp), quanto à existência do requisito de liderança e atribuição de responsabilidades no sistema de gestão de IA. OWASP GenAI Security Project, Top 10 for LLM Applications 2025 (owasp.org), quanto à recomendação de supervisão humana em operações de alto impacto como mitigação para autonomia excessiva. Databricks Documentation, Unity Catalog como camada de governança para dados e IA (docs.databricks.com). Atlassian, documentação de Jira e Jira Service Management sobre tipos de item, fluxo de aprovação e histórico de transições (atlassian.com). As observações sobre comportamento de equipes atribuídas a Lucio Figueiredo Matias são relato de experiência profissional, identificado como tal. Este conteúdo trata de governança técnica e não constitui aconselhamento jurídico










