Passo boa parte das minhas semanas em salas onde a mesma conversa se repete com roupas diferentes, e uma coisa me chamou atenção: a pergunta que me fazem mudou de natureza. Há dois anos ela era técnica — “qual modelo a gente usa?”. Hoje ela chega bem mais dura e bem mais desconfortável: “gastamos o orçamento do ano em IA, me mostre o que mudou no resultado”.

Levei um tempo para entender por que essa pergunta trava tanta gente, porque não é falta de resposta técnica. Quando eu puxo o fio, o padrão que encontro é quase sempre o mesmo: a empresa tem dezenas de iniciativas de IA rodando e ninguém consegue dizer quantas chegaram a produção, quais bases de dados elas tocam, nem quem responde se uma delas errar na frente de um cliente. Não falta tecnologia — nunca faltou. Falta governança. E, sem ela, adoção de IA vira custo recorrente disfarçado de inovação.

A discussão saiu do “se vamos usar” para “quem responde quando der errado”. Reguladores, auditoria interna e conselho passaram a cobrar rastreabilidade de decisão assistida por IA. Quem não tem inventário de casos de uso simplesmente não tem como responder.

O que é governança de IA?

Vou começar pelo que ela não é, porque é exatamente aqui que costumo perder a sala nos primeiros cinco minutos: governança de IA não é um comitê que aprova PowerPoint. Quando eu digo “governança”, o que a maioria escuta é “mais uma instância de aprovação” — e a resistência é imediata. Sendo honesto, ela é justificada, porque é assim que boa parte das iniciativas de governança realmente termina.

O que eu defendo é outra coisa. Governança de IA é o conjunto de regras, controles e cadências que define quem pode usar qual capacidade de IA, sobre quais dados, com qual nível de autonomia e sob qual responsabilidade. Encaro isso como decisão de arquitetura organizacional, não como processo burocrático — e essa distinção muda completamente o desenho.

A forma mais rápida que encontrei de explicar a diferença é colocar as duas realidades lado a lado. A primeira coluna não é caricatura: é o que eu encontro na maioria das avaliações iniciais.

Para mim, a diferença prática cabe em uma frase: na primeira coluna, a IA é um experimento perpétuo; na segunda, ela é um ativo de produção. E ativo de produção tem dono, custo e métrica.

O problema que resolve

Quando olho para trás e agrupo os casos que acompanhei, as dores se repetem em três formatos. Todas caras, todas evitáveis.

A primeira é o shadow AI, e é a que mais me incomoda porque também é a mais mal diagnosticada. Quando a empresa não oferece um caminho oficial, o time encontra o próprio — e dados sensíveis passam a trafegar por ferramentas fora do perímetro, sem log, sem retenção definida, sem contrato. Já vi essa situação ser tratada como problema disciplinar mais de uma vez, e nunca funcionou. O problema não é o profissional; é a ausência de uma via legítima e rápida.

A segunda é o piloto eterno: provas de conceito que impressionam na demo e nunca sobrevivem ao primeiro contato com carga real, dado sujo e requisito de auditoria. Demorei a enxergar a causa raiz, mas hoje ela me parece óbvia — elas morrem porque foram desenhadas para convencer, não para operar. São artefatos de venda interna, e o critério de sucesso delas se encerrou no momento em que a sala aplaudiu.

A terceira é o custo sem contrapartida. Tokens são baratos por unidade e caros em escala, e essa armadilha aritmética é subestimada com uma frequência que ainda me surpreende. Sem teto por caso de uso e sem métrica de valor, a conta cresce em silêncio até virar pauta de corte. E aí vem o pior desfecho possível: o corte chega linear e atinge justamente o caso de uso que estava dando certo, porque ninguém tinha número para defendê-lo.

Como funciona — passo a passo

O que vem abaixo não é framework de consultoria. É a ordem em que as coisas efetivamente funcionam quando existe pressa, orçamento apertado e um conselho pedindo resposta — e eu diria que a ordem importa mais do que cada item isolado.

1. Inventarie o que já existe. Antes de aprovar qualquer coisa nova, mapeie as iniciativas de IA em curso, oficiais e não oficiais. Você vai encontrar mais do que espera.
2. Classifique por risco, não por hype. Um assistente que resume ata interna e um motor que influencia concessão de crédito não podem passar pelo mesmo crivo.
3. Defina a política de uso em uma página. O que pode, o que não pode, quais dados são elegíveis, o que exige revisão humana. Se não cabe em uma página, ninguém vai ler.
4. Estabeleça o gate de produção. Nenhum caso de uso vira produção sem: dono nomeado, dado classificado, métrica com linha de base, plano de rollback e teto de custo.
5. Meça valor com linha de base. “Ficou mais rápido” não é métrica. Tempo de ciclo antes e depois, taxa de retrabalho, custo por transação — isso é.
6. Reavalie em cadência. Modelo, preço e capacidade mudam a cada trimestre. O caso de uso que não fechava conta há seis meses pode fechar hoje. E o contrário também.

Os perigos reais da IA (e nenhum deles é o robô assassino)

Confesso ter pouca paciência com a conversa pública sobre risco de IA. Enquanto se debate superinteligência em painel de evento, os incidentes que de fato chegam ao comitê de crise são bem mais prosaicos — e bem mais frequentes.

O primeiro é o vazamento por conveniência, e ele mudou a forma como eu desenho controle: o dado sensível quase nunca sai da empresa por má-fé, sai porque o caminho oficial era lento demais e alguém precisava entregar até sexta. Política que ignora essa assimetria de velocidade está condenada a ser contornada — e punir depois não recupera o dado que já saiu.

O segundo é a confiança calibrada errado, o que mais me preocupa tecnicamente. O modelo erra com exatamente a mesma fluência com que acerta: não há hesitação na voz, nem rodapé de incerteza, nem sinal visível de que aquela frase foi inventada. Em processo regulado, uma resposta errada bem escrita é mais perigosa do que nenhuma resposta, porque atravessa a revisão humana sem levantar suspeita. Para mim é um problema de interface, não de modelo.

O terceiro é o vácuo de responsabilidade, e considero o mais corrosivo. Quando a decisão passa a ser “da IA”, ela deixa de ser de alguém. Por isso insisto num humano nomeado por caso de uso — não como formalidade de compliance, mas por uma razão pragmática: sem esse nome, ninguém tem incentivo real para corrigir o sistema quando ele começa a derrapar.

Há ainda a dependência sem saída, o risco que eu, como arquiteto, mais sinto na pele: arquitetura acoplada a um único provedor, sem camada de abstração, transforma um reajuste de preço anunciado com trinta dias de antecedência em crise de orçamento sem alternativa técnica dentro do prazo.

E, por fim, o mais silencioso de todos: a perda de competência, o deskilling. Esse não produz incidente, produz erosão — e por isso quase nunca entra na matriz de risco. Quando o time delega julgamento, e não apenas execução, perde gradualmente a capacidade de auditar a própria ferramenta. O sintoma só aparece anos depois, quando alguém precisa explicar por que o sistema decidiu o que decidiu e não há mais ninguém na sala capaz de responder.

Do campo: os incidentes de IA que acompanhei raramente vieram do modelo. Vieram de permissão mal configurada, de prompt com dado sensível colado dentro e de processo que não previa revisão humana onde ela era obrigatória.

Do desenvolvedor de aplicações ao AI engineer

Essa é a transição de carreira mais acelerada que vejo hoje e, na minha leitura, a mais mal explicada.

O movimento já está em curso: desenvolvedores de aplicações sendo realocados para posições de AI engineer, onde a IA deixa de ser o produto final e passa a ser a ferramenta de trabalho. O dia a dia muda de forma — bem menos digitação de código, muito mais especificação, revisão e integração. O modelo escreve o rascunho; o profissional decide se aquilo entra no repositório e responde se entrar errado.

O que me chama atenção é a leitura equivocada que acompanha esse movimento: a de que a IA teria tornado o fundamento descartável. Minha experiência aponta para o oposto. Ler código continua sendo mais difícil e mais valioso do que escrevê-lo, e a IA multiplicou a quantidade de código a ser lida. Decisão de arquitetura, limite de transação, modelo de dados e contrato de API seguem sendo trabalho humano, porque dependem de um contexto de negócio que não cabe na janela do modelo. E há uma verdade incômoda que repito sempre que posso: quem não sabe avaliar uma solução também não sabe avaliar a solução que a IA propõe. A ferramenta não cria critério — apenas acelera quem já tem.

O que muda é a natureza da exigência. Engenharia de contexto passa a valer mais que sintaxe de prompt: saber o que colocar na janela do modelo e, sobretudo, o que deixar de fora separa uma resposta útil de uma alucinação plausível. Avaliação sistemática deixa de ser opcional, porque sem um conjunto de testes para a saída do modelo o “melhorou” vira opinião. Guardrails e observabilidade entram como requisito de engenharia, já que rastrear entrada, saída, custo e latência por chamada é o que permite operar com previsibilidade. E consciência de custo passa a fazer parte do desenho, porque o AI engineer costuma ser o primeiro a perceber quando uma escolha aparentemente inocente multiplica a fatura por dez.

Acima de tudo isso eu colocaria a revisão crítica. Aceitar sugestão de IA sem entender equivale a aprovar pull request sem ler — com o agravante de que agora o erro escala na velocidade da ferramenta, não na de quem digita.

Minha leitura executiva é direta: o desenvolvedor que só entregava código está exposto; o que entrega resultado, não. A IA comprimiu a parte mecânica do trabalho e ampliou o valor da parte que exige julgamento.

E há uma armadilha organizacional que preciso dizer com todas as letras, porque tenho visto acontecer: renomear o cargo não faz a transição. Trocar o título de “desenvolvedor” para “AI engineer” sem oferecer trilha de evals, contexto, custo e segurança não reposiciona ninguém — apenas transfere o risco da empresa para o indivíduo, cobrando dele uma competência que ela nunca ofereceu. Reposicionamento pertence à camada de governança, não ao RH isolado.

Como o mundo e os profissionais precisam se adaptar

Do lado da organização, a mudança mais importante é de enquadramento, e é também a que mais custa a emplacar: trilha de reposicionamento precisa ser tratada como controle de governança, não como benefício de RH. Quando consigo mover essa conversa de pauta, tudo muda — porque time despreparado operando ferramenta poderosa é risco operacional, e risco operacional tem dono, orçamento e prazo, coisa que benefício não tem.

Junto disso, eu sugeriria inverter um incentivo pouco óbvio: recompensar quem documenta o que a IA não deve fazer. Esse conhecimento é muito mais escasso que o inverso e é justamente ele que impede a repetição do erro caro. E, por fim, é preciso aceitar algo que a prática já demonstrou à exaustão — a defesa mais eficaz contra shadow AI nunca foi a proibição, e sim a existência de um caminho oficial genuinamente rápido. Enquanto a via legítima for mais lenta que a alternativa, a alternativa vence. Todas as vezes.

Do lado do profissional, o conselho que dou é sempre o mesmo, e vale tanto para quem me pergunta quanto para mim: suba na cadeia de decisão. A automação consome tarefa, não responsabilidade, e a fronteira entre as duas é exatamente onde a carreira se protege. Especialize-se onde o contexto é caro — domínio regulado, dado proprietário, integração legada — porque é precisamente aí que o modelo genérico é mais fraco, já que é aí que o conhecimento não está na internet.

E aprenda a auditar a IA, não apenas a operá-la. Operar qualquer pessoa aprende em uma semana; saber provar que a saída está errada é o que torna alguém insubstituível, justamente porque a ferramenta é falível por construção.

Boas práticas para produção

Nenhum dos pontos abaixo é teórico: cada um corresponde a um erro que eu já vi custar caro, e quase sempre custar duas vezes. Se houver apenas um a levar adiante, que seja o primeiro — a maior parte dos fracassos de governança que acompanhei começou por escrever a política antes de saber o que já estava rodando.

• Comece o inventário antes da política — regra escrita sobre realidade desconhecida não pega.
• Defina teto de custo por caso de uso no mesmo dia em que aprova o piloto.
• Exija linha de base numérica antes do primeiro deploy; depois é tarde para comparar.
• Registre prompt, versão de modelo e saída para casos de uso em processo regulado.
• Isole dados sensíveis por escopo de acesso, não por instrução no prompt. Instrução não é controle.
• Coloque uma camada de abstração entre a aplicação e o provedor de modelo desde o primeiro dia.
• Reavalie o portfólio a cada trimestre e desative o que não provou valor. Governança também é saber matar iniciativa.

Perguntas frequentes (FAQ)

Governança não vai atrasar a adoção?

É a objeção que mais escuto, e minha resposta é que o efeito costuma ser o inverso. O que atrasa adoção é retrabalho, incidente e piloto que não passa na auditoria. Governança bem desenhada é um caminho rápido com critério, não um obstáculo.

Por onde começar se não temos nada?

Pelo inventário, sempre. Uma planilha com caso de uso, dono, dado tocado e status já resolve os primeiros 80% da cegueira — e costuma ser o entregável que mais impressiona o conselho, justamente por ser o mais simples.

Quantas pessoas o time de governança precisa?

Menos do que se imagina. Na minha experiência funciona melhor como função distribuída — um responsável por domínio — do que como área centralizada, que quase sempre vira gargalo e, logo depois, vira alvo.

O desenvolvedor vai ser substituído pela IA?

Não pela IA. Eventualmente por outro profissional que usa IA com critério e entrega resultado auditável. A diferença está no julgamento, não na ferramenta.

Como medir valor de IA sem cair em métrica de vaidade?

Ignore número de usuários e volume de interações — são os números que enfeitam slide e não sustentam decisão. Meça tempo de ciclo, taxa de retrabalho e custo por transação, sempre contra uma linha de base anterior.

Conclusão

Se eu tivesse que resumir tudo em uma frase, seria esta: adoção de IA deixou de ser um problema de tecnologia e virou um problema de operação e responsabilidade. As empresas que vão capturar valor não são as que têm o melhor modelo — são as que sabem quais casos de uso estão rodando, quanto cada um custa, que dado ele toca e quem responde por ele.

O mesmo vale para a carreira, e aqui falo também por mim. A IA não elimina o profissional técnico; ela desloca o valor da execução para o julgamento. O desenvolvedor que vira AI engineer de verdade — com evals, contexto, custo e revisão crítica — fica mais relevante, não menos. O que só troca de crachá, esse sim fica exposto.

Governança não é o freio da adoção de IA. É o que permite pisar fundo sem sair da pista.

👉 Se você está liderando adoção de IA — especialmente em ambiente regulado, com auditoria no pescoço e conselho pedindo número, este é o momento de trocar entusiasmo por inventário.
Quer trocar ideia sobre governança de IA e reposicionamento de times técnicos? Me chama no LinkedIn.