Nvidia Sem Jensen Huang em 2026: O Que a Crise na Diretoria Ensina Sobre Risco de Pessoa-Chave
Olá HaWkers, a empresa que virou o centro da corrida de IA está diante da pergunta que nenhuma empresa grande gosta de responder em público: o que acontece se o fundador sair amanhã? Em 11/11/2026, o Wall Street Journal publicou que a diretoria da Nvidia estava se preparando para tirar Jensen Huang do cargo de CEO, posto que ele ocupa desde que cofundou a empresa em 1993. As ações caíram mais de 8% no after-hours no mesmo dia.
Eu não vou transformar este artigo em coluna de fofoca. O que me interessa aqui é outra coisa: como uma empresa desse tamanho chega a uma crise de liderança sem plano de sucessão claro, e o que isso ensina para quem trabalha com tecnologia, do time de três pessoas à empresa com milhares de engenheiros. Você sabe quem é a pessoa-chave do seu projeto? E sabe medir isso com dados, em vez de no feeling?
O Que Aconteceu, em Ordem
Vale separar o que foi confirmado do que ainda é reportagem. A situação muda rápido, então fique com a cronologia abaixo como o retrato de 12/11/2026.
- Semana anterior: o New York Times reportou que Huang teve um relacionamento com Alice Huang (sem parentesco com ele), ex-executiva da Megaspeed International, empresa de Singapura que comprou bilhões de dólares em chips e hardware da Nvidia. Segundo o jornal, agências de inteligência dos Estados Unidos acreditam há meses que ela foi recrutada pelo Ministério de Segurança do Estado da China. O Ministério das Relações Exteriores chinês chamou a narrativa de "totalmente infundada".
- Fim de semana: em mensagem aos funcionários, Huang reconheceu ter sido infiel à esposa, pediu desculpas à família e assumiu a responsabilidade, sem citar nomes.
- Domingo: a diretoria anunciou uma investigação independente sobre a alegação de que o CEO foi "alvo de um esforço de inteligência estrangeira" e disse não ter motivo para acreditar que segredos da empresa ou a segurança nacional tenham sido comprometidos.
- Quarta-feira, 11/11/2026: o Wall Street Journal reportou que a diretoria se preparava para afastá-lo. No mesmo dia, o New York Times publicou que Huang também teve um relacionamento com Kimberly Powell, vice-presidente de saúde da Nvidia e subordinada direta dele, citando pessoas que trabalharam na empresa. A diretoria se reuniu à noite e nenhuma decisão foi anunciada até o fechamento desta edição.
Paralelo a isso, o Departamento de Justiça americano estaria investigando a Megaspeed por possíveis violações de controle de exportação, e a Nvidia enfrenta uma ação de investidores que acusa a empresa de não ter divulgado informações sobre o caso.
O próximo marco é concreto: a Nvidia divulga resultados trimestrais em 17/11/2026.
Por Que Isso Importa Muito Além de Wall Street
A reação do mercado diz muito. Segundo o The Next Web, se a queda do after-hours se mantiver, a Nvidia terá perdido cerca de US$ 600 bilhões em valor de mercado desde o início da investigação. Na Polymarket, a probabilidade de Huang renunciar ou ser removido até o fim do ano chegou a 88%.
Armina Rosenberg, da Minotaur Capital, resumiu bem: "O mercado está começando a precificar a Nvidia sem o fundador como o resultado provável, não como um risco de cauda."
E aqui está o ponto que interessa para quem escreve código: a Nvidia não é só uma ação. É a empresa por trás do CUDA, do ecossistema de bibliotecas que roda boa parte do treinamento e da inferência de IA no mundo, e de uma cadeia de fornecimento da qual dependem nuvens, startups e laboratórios. Uma troca de comando mal feita afeta roadmap, preço, prioridade de produto e relação com parceiros.
Os números do negócio, aliás, estão longe de ser de crise. Segundo a Fortune, a receita do primeiro semestre do ano fiscal de 2027 foi de US$ 96 bilhões, alta de 85% na comparação anual, e a CFO Colette Kress projetou crescimento de 70% da receita no ano fiscal de 2028. O problema não é o produto. É a governança.
A Anatomia de um Risco de Pessoa-Chave
Risco de pessoa-chave (key person risk) é quando o funcionamento de uma organização depende tanto de uma pessoa que a saída dela, por qualquer motivo, gera uma ruptura. A reportagem da Fortune descreve a Nvidia com vários sintomas clássicos:
- Estrutura plana extrema: Huang tem cerca de 60 subordinados diretos e é central na maioria das decisões.
- Sem presidente do conselho separado e sem diretor de operações (COO).
- Sem plano de sucessão público: o conselho estaria trabalhando com uma empresa externa para buscar substitutos só agora.
Michael Useem, professor da Wharton, foi direto à Fortune: "Se o conselho estivesse fazendo o seu trabalho, já teria uma lista de possíveis sucessores." E Gil Luria, da D.A. Davidson, disse que os fatores por trás da possível saída "aceleram uma transição para a qual a empresa não está preparada".
Os nomes que circulam para um comando interino incluem a CFO Colette Kress, o diretor independente líder Stephen Neal e, segundo a Bloomberg, Ian Buck, vice-presidente de computação de alto desempenho. Para o cargo definitivo, Johny Srouji, chefe de hardware da Apple, aparece em reportagens. Nada disso está confirmado.
Do ponto de vista de governança, o mecanismo existe: o estatuto da Nvidia permite que a maioria dos 11 diretores destitua o CEO, com ou sem justa causa. Ter o mecanismo não é o mesmo que ter um plano.
O Mesmo Problema, em Escala de Time: o Bus Factor
Em software a gente tem um nome bem menos elegante para isso: bus factor, ou fator ônibus. É o número mínimo de pessoas que precisariam sair do projeto para ele travar. Bus factor 1 significa que uma única saída já para tudo.
A boa notícia é que dá para medir uma aproximação disso com o próprio histórico do Git. O script abaixo olha, arquivo por arquivo, quem escreveu a maior parte das linhas e aponta os arquivos onde uma pessoa só domina o código.
#!/usr/bin/env bash
# bus-factor.sh - lista arquivos onde um único autor concentra o conhecimento
# Uso: ./bus-factor.sh [limite_percentual] (padrão: 80)
set -euo pipefail
LIMITE="${1:-80}"
# Percorre apenas arquivos versionados de código (ajuste as extensões)
git ls-files '*.ts' '*.js' '*.vue' '*.py' | while read -r arquivo; do
# git blame --line-porcelain gera uma linha "author X" por linha do arquivo
autores=$(git blame --line-porcelain -- "$arquivo" 2>/dev/null \
| grep '^author ' | sed 's/^author //' | sort | uniq -c | sort -rn)
total=$(echo "$autores" | awk '{s+=$1} END {print s+0}')
[ "$total" -eq 0 ] && continue
# Primeiro da lista é quem mais escreveu linhas nesse arquivo
top_linhas=$(echo "$autores" | head -1 | awk '{print $1}')
top_autor=$(echo "$autores" | head -1 | sed 's/^ *[0-9]* //')
pct=$(( top_linhas * 100 / total ))
if [ "$pct" -ge "$LIMITE" ]; then
echo "${pct}% | ${top_autor} | ${arquivo}"
fi
done | sort -rnRode na raiz do repositório. Se a lista vier cheia do mesmo nome, você encontrou a sua versão do problema da Nvidia, só que em escala menor.
Uma ressalva honesta: linhas de código não são conhecimento. Quem fez o último refactor grande "ganha" o arquivo no git blame, mesmo sem entender a regra de negócio. Use o número como ponto de partida para uma conversa, não como veredito.
Medindo Concentração por Área, Não Só por Arquivo
Arquivo isolado engana. O que costuma doer é quando uma área inteira, como pagamentos, autenticação ou o pipeline de deploy, só tem uma pessoa que mexe nela. Este script em Node agrega commits recentes por diretório e calcula quantas pessoas diferentes tocaram em cada área.
// area-owners.mjs - quantas pessoas mexeram em cada diretório nos últimos 6 meses
// Uso: node area-owners.mjs
import { execSync } from 'node:child_process';
// Formato: marcador de autor seguido da lista de arquivos de cada commit
const log = execSync(
'git log --since="6 months ago" --name-only --format="@@%an"',
{ encoding: 'utf8', maxBuffer: 64 * 1024 * 1024 }
);
const areas = new Map(); // diretório -> Map(autor -> commits)
let autorAtual = null;
for (const linha of log.split('\n')) {
if (linha.startsWith('@@')) {
autorAtual = linha.slice(2);
continue;
}
if (!linha.trim() || !autorAtual) continue;
// Considera os dois primeiros níveis como "área" (ex: server/api)
const area = linha.split('/').slice(0, 2).join('/');
if (!areas.has(area)) areas.set(area, new Map());
const autores = areas.get(area);
autores.set(autorAtual, (autores.get(autorAtual) ?? 0) + 1);
}
const relatorio = [...areas.entries()]
.map(([area, autores]) => {
const total = [...autores.values()].reduce((a, b) => a + b, 0);
const [lider, commits] = [...autores.entries()].sort((a, b) => b[1] - a[1])[0];
return { area, pessoas: autores.size, lider, concentracao: Math.round((commits / total) * 100) };
})
// Áreas com uma ou duas pessoas são as mais frágeis
.filter((r) => r.pessoas <= 2)
.sort((a, b) => b.concentracao - a.concentracao);
console.table(relatorio);O resultado é uma tabela com as áreas mais frágeis no topo. Na minha experiência, ela quase sempre confirma o que o time já desconfiava, mas ter o número em mãos muda a conversa com a liderança: deixa de ser "acho que só o fulano sabe mexer nisso" e vira "nos últimos seis meses, 94% dos commits dessa área vieram de uma pessoa".
Transformando o Diagnóstico em Regra
Medir sem agir não resolve nada. A forma mais barata de forçar a distribuição de conhecimento é tornar a revisão de uma segunda pessoa obrigatória nas áreas críticas. No GitHub isso se faz com CODEOWNERS somado a uma regra de proteção de branch que exige aprovação dos donos.
# .github/CODEOWNERS
# Cada área crítica tem pelo menos DUAS pessoas responsáveis.
# Se uma sair, a outra continua aprovando e o conhecimento não some.
/server/api/payments/ @ana-silva @bruno-costa
/server/api/auth/ @carla-souza @ana-silva
/infra/ @diego-lima @carla-souza
# Padrão para o resto do repositório: o time inteiro
* @minha-org/engenhariaOs nomes acima são exemplos, troque pelos usuários reais do seu time. O detalhe importante é a regra de ouro: nenhuma linha com um único nome nas áreas que derrubam o produto se pararem.
Outras práticas que funcionam na mesma linha:
- Rodízio de plantão: quem nunca atendeu um incidente na área não aprende a área.
- Pareamento em mudanças grandes: a pessoa que mais conhece o código pareia com quem menos conhece.
- Documento de decisão (ADR): registre o porquê, não só o como. O porquê é o que vai embora junto com a pessoa.
- Férias de verdade: se o time não sobrevive a duas semanas sem alguém, você descobriu o bus factor sem precisar de script.
E o Risco de Fornecedor Único?
Tem uma segunda lição aqui, mais técnica. Se a Nvidia passar por uma transição turbulenta, quem tem todo o stack amarrado a uma única plataforma sente primeiro. Não estou dizendo que o CUDA vai desaparecer, nem perto disso. Estou dizendo que código que só roda em um fornecedor é um risco de pessoa-chave em outra escala.
Em PyTorch, o primeiro passo é parar de espalhar .cuda() pelo código e centralizar a escolha do dispositivo:
# device.py - escolhe o melhor acelerador disponível sem amarrar o código a um fornecedor
import torch
def escolher_dispositivo() -> torch.device:
# Builds do PyTorch para ROCm (AMD) também expõem a API torch.cuda,
# então este ramo cobre GPUs Nvidia e AMD
if torch.cuda.is_available():
return torch.device("cuda")
# Apple Silicon usa o backend MPS (Metal Performance Shaders)
if torch.backends.mps.is_available():
return torch.device("mps")
# Sem acelerador: continua funcionando na CPU, só que mais devagar
return torch.device("cpu")
DISPOSITIVO = escolher_dispositivo()
if __name__ == "__main__":
print(f"Rodando em: {DISPOSITIVO}")
# Modelos e tensores recebem o dispositivo de um único lugar
modelo = torch.nn.Linear(16, 4).to(DISPOSITIVO)
entrada = torch.randn(8, 16, device=DISPOSITIVO)
print(modelo(entrada).shape)Isso não elimina a dependência, mas deixa explícito onde ela está. Quando você precisar testar outro hardware ou outra nuvem, a mudança fica em um arquivo, não em duzentos.
Vale também saber quanto do seu projeto depende diretamente de pacotes específicos de um fornecedor. Um pip list | grep -i nvidia dentro do ambiente virtual já mostra os pacotes nvidia-* que entraram como dependência. Não é motivo para pânico, é inventário. Quem conhece o próprio inventário reage melhor quando o mercado muda.
O Que Observar nos Próximos Dias
Alguns sinais vão dizer para onde isso vai:
- Comunicado oficial da diretoria. Até agora, tudo sobre a saída de Huang vem de reportagens com fontes anônimas. Só o comunicado da empresa fecha a questão.
- Resultado trimestral em 17/11/2026. Se a decisão sair antes, a teleconferência com analistas vai ser dominada pela sucessão. Se sair depois, o tom do resultado vai pesar.
- Nome do comando interino. Uma escolha de dentro da casa, como a CFO, sinaliza continuidade. Um nome de fora sinaliza mudança de rumo.
- Desdobramentos regulatórios. A investigação sobre a Megaspeed e controle de exportação para a China pode ter impacto mais duradouro do que a troca de CEO em si.
O professor Jeffrey Sonnenfeld, de Yale, comparou o caso à saída de Steve Easterbrook do McDonald's em novembro de 2019, quando a investigação revelou relacionamentos impróprios além do que estava sendo apurado. É uma comparação que mostra como esse tipo de crise costuma crescer antes de encolher.
Se você quiser entender o tamanho da Nvidia no ecossistema de IA antes dessa crise, recomendo ler o que eu escrevi sobre a compra da Hugging Face pela Nvidia por US$ 12,9 bilhões. Ajuda a dimensionar o quanto da IA aberta passa hoje pela mesma empresa.
Perspectivas
A crise da Nvidia ainda não terminou e pode ter um desfecho diferente do que as reportagens apontam hoje. Mas a lição já está dada, independentemente do resultado: uma empresa avaliada em trilhões de dólares chegou ao momento mais delicado da sua história sem um plano de sucessão pronto.
Para quem lidera time, a pergunta é a mesma em escala menor. Se a pessoa que mais sabe do seu sistema não aparecer na segunda-feira, o que para? Rode os scripts deste artigo, olhe os números com calma e escolha uma área para dividir o conhecimento ainda neste mês. É o tipo de trabalho que nunca parece urgente, até o dia em que vira a única coisa urgente.
Bora pra cima! 🦅
📚 Quer Acompanhar o Que Vem Por Aí?
Este artigo cobriu a crise de liderança na Nvidia e como medir o risco de pessoa-chave no seu time, mas o ecossistema muda toda semana e nem tudo vira artigo aqui.
No X eu compartilho o que estou testando, os bastidores dos projetos e as novidades que aparecem antes de virarem post.
Me Segue Lá
💡 Conteúdo diário sobre desenvolvimento, carreira e as ferramentas que eu realmente uso