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

Guilherme Matos • August 19, 2026

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

Fale com a CSP Tech

.

Por Guilherme Matos 20 de agosto de 2026
Case impressiona, pergunta técnica revela. Nove perguntas específicas de plataforma que separam quem operou Databricks em produção de quem conhece a teoria, com o sinal de alerta de cada resposta.
Por Guilherme Matos 18 de agosto de 2026
A ISO/IEC 42001 é a primeira norma internacional de sistema de gestão de IA. Ela não pede tecnologia, pede evidência. Veja o que a norma exige, o que a diferencia da ISO 27001 e por que documento não substitui rastro operacional.
economia de tokens, como reduzir custo de IA no desenvolvimento; qual o custo do token de IA
Por Romildo Burguez 18 de agosto de 2026
Sua equipe usa o modelo mais caro por hábito, não por necessidade. Entenda como a economia de tokens reduz custo de IA sem travar as entregas.
Por Guilherme Matos 17 de agosto de 2026
O humano hesita diante de uma tarefa ambígua. O agente de IA não hesita: ele entrega errado em minutos. Veja por que critérios de aceite deixaram de ser ritual ágil e viraram o ponto onde custo, qualidade e conformidade são decididos. 
Por Guilherme Matos 14 de agosto de 2026
A escolha de uma consultoria de IA se decide em três planos, e avaliar apenas o primeiro é o erro mais caro do processo. O plano da capacidade responde se o fornecedor domina a fundação que a IA exige para funcionar em produção: dado governado para consultar, sistema onde agir de forma rastreável e leitura que prove valor. O plano do contexto responde se ele está preparado para as condições brasileiras: obrigações da LGPD sobre tratamento e retenção, decisões de residência e trânsito de dados, e custo de consumo cotado em moeda estrangeira. O plano do modelo de trabalho responde como o fornecedor opera: o que ele faz nas primeiras semanas, o que registra e o que se recusa a vender. Demonstração impressiona nos três e comprova nenhum, porque roda sobre dado escolhido e escopo controlado.
Por Guilherme Matos 13 de agosto de 2026
Um defeito de QA e uma exposição de dado pessoal podem ser o mesmo achado, e o QA tradicional classifica com a régua errada. Veja por que rastreabilidade virou evidência de diligência e o que muda quando a IA acelera a produção de código.
Por Guilherme Matos 12 de agosto de 2026
Memória de IA não é propriedade dada, é decisão de arquitetura com custo explícito. E tudo o que o sistema lembra é dado retido. Veja por que minimizar contexto atende ao orçamento e ao princípio da necessidade ao mesmo tempo.
Por Guilherme Matos 11 de agosto de 2026
O Gartner aponta que a maioria das empresas ainda não tem framework para medir custo de IA contra impacto de negócio. A fatura chega agregada, mas a unidade econômica é a entrega. Veja as três camadas que tornam o custo por entrega mensurável.
segurança do código gerado por IA; código gerado por IA é seguro?; vulnerabilidades em código de IA
Por Romildo Burguez 10 de agosto de 2026
Quase metade do código gerado por IA tem falhas de segurança. Veja o que os dados mostram e como estruturar a validação no seu ciclo de desenvolvimento