Nem toda empresa precisa de IA

TL;DR — «Nem toda empresa precisa de IA» não é slogan contra ferramenta. É um recorte de contexto. A mesma IA que, na mão de um profissional experiente, dentro de uma empresa governada, vira alavanca, na mão de quem só sente a dor — e ainda está montando a primeira stack — vira atalho com efeito colateral: o sistema sobe, o cliente entra, e um pedaço da base sai pelo prompt. Empresa grande com SSO, DLP e tenant enterprise não está imune (shadow AI existe lá também). Empresa no início da jornada de TI não está proibida de usar IA para acelerar — na verdade, muitas vezes não tem outro jeito. O que muda é o piso: o que nunca entra no modelo, quem revisa o que sai, e a diferença brutal entre multiplicar competência e multiplicar improviso.

Gravei isso em um short no Mackenzie. A provocação cabia em um minuto: muita empresa corre para IA sem confiar no próprio dado. Este texto é o desdobramento que o minuto não comporta — porque o mercado de 2026 mudou o problema.

Não é mais «IA é hype, ignore».Agente já está em produção. Também não é «toda empresa precisa de um agente até o fim do trimestre». A pergunta útil é outra: quem está usando, em que maturidade de empresa, e o que está colando na caixa de texto.

A frase não é um veto. É um teste.

«Precisa» é uma palavra preguiçosa quando ninguém define de quê.

Precisa de um chatbot no site? De copiloto no editor? De um modelo treinado com a base de clientes? De um agente com permissão de escrever no ERP? São quatro decisões diferentes, com quatro raios de explosão diferentes. Empacotar tudo como «adotar IA» é o mesmo erro de chamar dashboard de cultura de dados.

O teste é simples, e é o mesmo que eu usaria antes de qualquer ferramenta cara:

Qual decisão essa IA muda — e quem é o dono dela?
Qual o custo de errar se o modelo fluir com segurança sobre um dado errado ou sobre um segredo que não deveria ter visto?
O dado que alimenta essa IA já tem definição única e alguém que responda por ele?
Existe um humano que revisa o que sai no ponto em que o erro é caro?

Se a resposta para (1) é «ficar moderno» e a resposta para (4) é silêncio, você não precisa de IA. Precisa de operação. É a mesma tese de antes de ser data-driven, a empresa precisa confiar nos dados — agora com uma camada a mais: o modelo não só erra o número. Ele carrega o número, o código e o cliente para fora do perímetro.

Duas empresas, a mesma ferramenta, dois riscos

Imagine o mesmo produto — ChatGPT, Claude, Copilot, Cursor — aberto em duas mesas.

Na primeira, uma empresa grande, regulada, com time de segurança, classificação de dado, SSO, DLP, ferramenta aprovada no tenant, contrato enterprise que diz que o prompt não treina o modelo de fundação, log de uso, e alguém com autoridade para dizer não. Ainda assim ela tem gente colando texto no ChatGPT pessoal no celular, porque a ferramenta aprovada é lenta ou porque «é só um resumo». Shadow AI não é privilégio de startup. É o nome novo de um hábito antigo: o caminho mais curto quando o processo oficial atrapalha o prazo.

Na segunda, uma empresa que está começando a jornada de TI. Não tem CISO. Não tem classificação. O WhatsApp é repositório. O fundador, o analista e o «sobrinho que manja de sistema» são o departamento inteiro. A IA não é um piloto. É o jeito de entregar no prazo que o caixa pede. Gerar landing, CRUD, integração com pagamento, relatório para o investidor, e-mail para o cliente. Sem IA, a empresa simplesmente não constrói.

Tratar essas duas mesas como se fossem o mesmo problema é desonestidade técnica. Tratar só a segunda como irresponsável também é. A primeira tem governança — e ainda vaza pelo uso pessoal. A segunda precisa da velocidade — e muitas vezes não sabe o que acabou de colar.

	Empresa governada e segura	Empresa iniciando a jornada de TI
Por que usa IA	Produtividade com controle; ferramenta no tenant	Sobrevivência de prazo e de caixa; a IA é o time
O que já existe	SSO, DLP, classificação, contrato, log, alguém que veta	Quase nada disso — e dado sensível existe do mesmo jeito
Risco típico	Shadow AI (prompt no tool pessoal) + copiloto que amplifica oversharing interno	Prompt com cliente, contrato, `.env`, dump, planilha; código gerado indo para produção sem revisão de auth
Ilusão comum	«Temos política, então estamos seguros»	«Não somos grande o bastante para ser alvo»
O que de fato precisa	IA governada, não mais abas anônimas	Velocidade com piso — não veto, não faroeste

«Não somos grande o bastante para ser alvo» é a frase que mais barateia incidente. Você não precisa ser a Samsung para ter CPF de cliente, chave PIX, contrato, senha de SMTP e um dump de teste que na verdade é produção. A LGPD (Lei 13.709/2018) não pergunta o faturamento antes de aplicar os princípios de finalidade, necessidade e segurança. Transferir dado pessoal para um provedor no exterior, sem base legal e sem saber o que o provedor faz com o prompt, não vira «inovação». Vira tratamento irregular.

O caso que o mercado já conhece — e o que ele realmente ensina

Em março de 2023, engenheiros da divisão de semicondutores da Samsung colaram no ChatGPT, em episódios separados, código-fonte, notas de reunião interna e dados de teste. A empresa tinha autorizado o uso. A intenção de cada um era fazer o trabalho mais rápido: debugar, resumir, calcular. Em maio, a Samsung proibiu chatbots generativos em dispositivos da companhia.

Três lições que o slide de «IA responsável» costuma pular:

Ninguém estava sabotando. Cada prompt era um profissional tentando entregar. Incidente de IA, no começo, parece produtividade.
Autorizar a ferramenta não é o mesmo que controlar o que entra nela. A Samsung autorizou. O que faltava era o piso: o que nunca se cola.
No plano consumer da época, o que saía não voltava. Termo de uso permitia uso para treino. Empresa enterprise, depois, passou a vender exatamente o contrário — e isso importa, mas não resolve o celular pessoal nem o plugin de terceiro.

A OWASP, no Top 10 para aplicações de LLM (2025), coloca LLM02: Sensitive Information Disclosure logo atrás de prompt injection. Não é um risco teórico de paper. É o nome formal do que acontece quando PII, credencial, código proprietário ou documento jurídico entram no contexto do modelo e depois saem — no log, no treino, na resposta de outro usuário, ou simplesmente no servidor de um fornecedor que você não contratou de verdade.

Microsoft, no Copilot 365, foi honesta o bastante sobre outro ângulo: a proteção enterprise (dado do tenant não treina o modelo de fundação) não cria oversharing. Ela revela o oversharing que já estava no SharePoint, no «qualquer um com o link», na pasta de RH que ninguém travou. Copiloto com permissão herdada é útil. Copiloto em cima de ACL podre é um mecanismo de descoberta instantânea do que a empresa fingiu que estava privado.

Traduzindo: governança de ferramenta sem governança de dado e de acesso só deixa o vazamento mais eloquente.

Dois profissionais, o mesmo prompt

Aqui está o corte que o debate de «vibe coding» trata com desprezo ou com ufanismo — os dois errados.

Há o profissional que tem ofício. Já quebrou produção, já leu log, já recusou um SELECT * sem WHERE, já viu um .env ir para o Git. Ele usa IA o dia inteiro. Deve usar. É alavanca: boilerplate, teste, primeira versão da query, rascunho do runbook, explicação de um trecho legado. A diferença não é que ele «não precisa» de IA. É que ele sabe o que a IA não pode decidir no lugar dele.

Ele não cola a base de clientes para «pedir um insight». Não manda a chave da AWS para «ver se está no formato certo». Não aceita o CRUD gerado sem olhar authz — quem pode ler o quê, em qual tenant, com qual papel. Não trata fluência como revisão: o modelo escreve código que parece de quem sabe, inclusive o comentário educado em cima do buraco. Isso é primo do que já discutimos sobre o «pensamento» da IA que você lê não ser o que ela está fazendo: texto coerente não é evidência de processo correto.

Há o profissional que manja da dor e tem zero chão técnico. Fundador, analista, operação, comercial que cansou de esperar TI. Essa pessoa não é o vilão desta história. Em vários momentos, ela salva a empresa: tira o primeiro produto do papel, atende o cliente que ia embora, monta o fluxo que o time senior só ia começar no trimestre que vem. Sem ela, muita companhia no início simplesmente não existe.

O risco não é a dor. A dor é o ativo. O risco é que a IA oferece uma simulação de ofício. O sistema sobe. A tela funciona. O Pix cai. E no caminho foram-se:

a planilha de clientes colada «só para gerar o e-mail»
o dump «de teste» que tinha CPF, telefone e compra
o .env inteiro, porque o erro de conexão era chato e o chat pediu o arquivo
a policy de S3 public-read, porque o tutorial gerado não falou em bucket privado
o endpoint de admin sem autenticação, porque «depois a gente põe login»

Quem só sente a dor não vê esses objetos como incidente. Vê como obstáculo. O modelo, solícito, remove o obstáculo — e leva o dado junto.IA sem dados confiáveis só automatiza confusão. Aqui o complemento é mais seco: IA sem ofício automatiza exposição.

	Profissional com ofício + IA	Profissional da dor, zero técnico + IA
O que a IA faz	Multiplica o que ele já sabe revisar	Substitui o ofício que ele não tem
O que ele cola	Trecho sanitizado, dúvida pontual, código sem segredo	O problema inteiro: base, contrato, senha, print com dado
O que ele recusa	Auth genérico, SQL concatenada, secret no repo, permissão ampla	Quase nada — se rodou, «funcionou»
Valor real	Velocidade com threat model	Destrave de caixa e de produto, de verdade
Falha típica	Excesso de confiança no diff que «parece certo»	Expor dado sensível sem perceber que expôs
Como usar bem	IA no loop, humano no gate de segurança	IA com piso escrito+ um par técnico no que toca dado e auth

Não é moralismo de senior contra quem está começando. É física do risco: a mesma alavanca aumenta força. Se a força aponta para o lugar certo, você constrói. Se aponta para o prompt com a base, você constrói um incidente com interface bonita.

A empresa no início vai usar IA. O erro é fingir que não.

Quem escreve política de banco e aplica na empresa de seis pessoas está representando. Quem diz «proíbam ChatGPT» para um time que não tem desenvolvedor está escolhendo não entregar.

O uso intensivo de IA para criar — código, copy, processo, relatório — é racional no começo. O custo de um time senior completo é maior do que o caixa. A alternativa realista não é «contrate três staff engineers». É admitir a alavanca e pagar o piso, que é barato perto do incidente.

Piso, não teatro:

Lista do que nunca entra em modelo público. Credencial, dump, PII, contrato, chave PIX, dado de saúde, conversa de cliente, .env. Escrito. Na parede. Sem eufemismo.
Conta certa. Plano consumer e aba anônima não são «a mesma Claude». Tenant enterprise / API com contrato de não-treino e retenção é outra espécie jurídica. Se o caixa não paga isso ainda, o piso (1) fica mais duro — não mais frouxo.
Dado de cliente não é insumo de prompt. Anonimize, sintetize, recorte. Se precisa do caso real, trate como transferência de dado pessoal, não como «contexto para o modelo».
Código gerado não vai para produção sem um olho em auth, segredo e permissão. Login, papel, tenant, upload, SQL, CORS, bucket. É uma lista curta. É a lista que o incidente usa.
Um par técnico no gate. Não precisa ser um departamento. Precisa de alguém que consiga ler o que a IA gerou e dizer «isso abre o banco». Sem essa pessoa, o profissional da dor continua valioso — e continua perigoso no mesmo movimento.
Log mínimo do que foi colado onde. Empresa grande já exige. Empresa pequena pode começar pelo hábito: se foi dado de cliente, não foi chat.

Nada disso é CISO. É higiene. Higiene é o que pipeline sempre foi: a parte chata que sustenta a decisão. IA só tornou a parte chata impossível de continuar adiando — porque agora a decisão e o vazamento saem no mesmo Enter.

A empresa grande também não está «pronta só porque tem política»

O avesso merece a mesma honestidade.

Governança de papel, ferramenta aprovada e treinamento anual não fecham o celular pessoal. DLP que não vê o prompt no browser não é DLP de IA. Copiloto ligado em cima de SharePoint aberto é um motor de busca do que vocês não queriam que o estagiário visse. Agente com credencial de serviço ampla é o atalho que a pesquisa de 2026 sobre agentes já traduziu: permissão herdada, não ampliada.

Lá, «precisa de IA» quase sempre significa precisa de IA no perímetro. Fora do perímetro, é o mesmo risco da empresa pequena, só que com base maior.

O que «precisa» passa a significar

Nem toda empresa precisa de agente apontado para o dado operacional. Quase toda vai usar algum modelo para escrever, resumir ou gerar código. Confundir as duas frases é o que gera o slide vazio e o incidente discreto.

Empresa governada: precisa de controle no uso, não de mais modelo. O profissional experiente, ali, é o multiplicador correto — se o oversharing interno estiver fechado.
Empresa no início: precisa da velocidade, e vai tê-la com gente que manja da dor. Isso não é fracasso. É o recorte. O fracasso é deixar essa pessoa sozinha no prompt com a base, sem piso e sem par técnico.
Profissional com ofício: deve usar IA sem culpa. Recusar a alavanca por purismo é tão teatrístico quanto o hype. O ofício agora inclui revisar o que o modelo inventou com cara de certo.
Profissional da dor: continua sendo quem tira a empresa do atoleiro. Só não pode ser, sozinho, o security engineer, o DPO e o DBA que o modelo fingiu que ele era.

A verdade técnica, desta vez, não é agradável para nenhum dos dois times. Para o time que quer vender IA em toda reunião: não, nem toda empresa precisa — e algumas que «precisam» precisam primeiro de um não. Para o time que quer se sentir superior porque não cola nada no chat: sim, a empresa pequena vai usar, e tem razão em usar; o seu trabalho é ensinar o piso, não o veto.

Quem domina não precisa gritar «IA first» nem «IA never». Precisa saber em qual mesa está sentado, quem está colando, e o que não pode atravessar essa borda.

Fontes

Provocação original (vídeo): DataDriks.Nem toda empresa precisa de IA. Gravado na Universidade Presbiteriana Mackenzie.https://www.youtube.com/shorts/i0NQWBtSlh4
Incidente Samsung / ChatGPT (2023): Ray, S.Samsung Bans ChatGPT And Other Chatbots For Employees After Sensitive Code Leak. Forbes, 2 mai. 2023. Relato jornalístico do caso e da proibição interna.https://www.forbes.com/sites/siladityaray/2023/05/02/samsung-bans-chatgpt-and-other-chatbots-for-employees-after-sensitive-code-leak/
LLM02 — divulgação de informação sensível: OWASP.Top 10 for Large Language Model Applications 2025. Sensitive Information Disclosure (PII, credencial, dado confidencial, código).https://owasp.org/www-project-top-10-for-large-language-model-applications/
Perímetro enterprise vs. aba consumer: políticas públicas de não-treino em planos enterprise (OpenAI, Anthropic, Microsoft 365 Copilot / Enterprise Data Protection). A proteção do tenant não se estende ao ChatGPT pessoal aberto no minuto seguinte; Microsoft também documenta oversharing interno como risco de rollout de Copilot (ACL pré-existente).
Dado pessoal no Brasil: Lei nº 13.709/2018 (LGPD), princípios de finalidade, necessidade e segurança; regras de transferência internacional (arts. 33–36). O porte da empresa não anula o fato de o prompt com cliente ser tratamento de dado.
Agentes em produção e gargalo de dado (contexto interno): Anthropic & Material.The 2026 State of AI Agents Report — discutido em Agente de IA já está em produção — e o gargalo é o seu dado.