a notícia do Sapo.pt e a primeira coisa que pensei não foi geopolítica — foi no impacto direto em quem desenvolve, integra ou implanta robôs e dispositivos IoT. A FCC acabou de expandir a “Covered List” e, na prática, fechou a porta dos EUA para novos robôs humanoides e quadrúpedes fabricados no estrangeiro. Parece abstrato, mas para quem trabalha com ROS, ROS 2, edge AI ou computação física, isso muda o cálculo de compras, fornecedores e arquitetura de projetos. Vou destrinchar o que aconteceu, o que isso significa tecnicamente e o que você, dev, deveria estar olhando agora.
O que a FCC decidiu, de fato
Segundo o Sapo.pt, a Comissão Federal de Comunicações dos EUA anunciou a expansão da Covered List para incluir duas novas categorias: robôs humanoides e robôs quadrúpedes produzidos fora dos Estados Unidos. A medida não é retroativa — quem já tem autorização da FCC pode continuar comercializando — mas qualquer modelo novo, estrangeiro, não pode mais ser importado ou vendido nos EUA.
Fabricantes estrangeiros ainda podem pedir uma approval condicional, desde que provem que seus produtos não representam “riscos inaceitáveis”. O ponto-chave da justificativa da FCC é que esses equipamentos podem ser explorados para:
- Vigilância de cidadãos americanos;
- Reforço de capacidades de serviços de informação estrangeiros;
- Comando remoto malicioso dos próprios dispositivos.
Isso nada mais é do que o velho problema de supply chain de hardware, mas agora batendo na porta da robótica de consumo e industrial. Quem trabalha com embedded systems reconhece o cheiro: é a mesma lógica que fez a Huawei virar caso de segurança nacional anos atrás.
Por que isso importa para devs (muito mais do que parece)
Três pontos que a notícia não aprofundou e que afetam diretamente o nosso trabalho:
1. Acelerômetro, câmera, microfone e rede são a nova fronteira de ataque
Robôs humanoides e quadrúpedes são, essencialmente, computadores sobre rodas com um arsenal de sensores ativos o tempo todo: LiDAR, IMU, câmeras RGB/IR, microfones omnidirecionais e módulos de comunicação (Wi-Fi, 5G, BLE). Cada sensor é uma superfície de ataque. Um modelo de robô que você compra pronto já vem com firmware rodando — e, na maioria das vezes, sem a possibilidade real de auditar linha por linha.
Quando você instala um humanoid_v2.3.bin fornecido pelo fabricante, está confiando na cadeia inteira: quem compilou, quem assinou, quem mantém a chave privada. Em software, a gente lida com isso via SBOM e verificação de assinatura. Em hardware, poucos fazem.
2. Frameworks de robótica são majoritariamente open source — o hardware, não
O ecossistema de software para robótica gira em torno de ROS, ROS 2, MoveIt, Nav2, e ultimamente Isaac Lab (NVIDIA) e MuJoCo. Tudo código aberto, auditável. O problema é que esse software roda em cima de hardware proprietário. Se a camada física vier comprometida, todo o cuidado com a camada de software é inútil.
É o mesmo princípio de “you can’t outrun bad hardware with good software” que a gente já conhece em sistemas embarcados críticos.
3. Edge AI e inferência on-device ficam ainda mais no centro do debate
Modelos de IA rodando localmente no robô (sem envio de telemetria para nuvem) são a melhor defesa contra espionagem de dados sensíveis. Mas isso exige GPUs potentes, NPUs e stacks compatíveis — exatamente o tipo de coisa que a maioria dos fabricantes chineses baratos de robots entrega precariamente, com chipsets vindo do próprio ecossistema sob suspeita.
A justificativa técnica por trás da decisão (e onde ela faz sentido)
A FCC listou três vetores de risco. Vou traduzir para linguagem de dev:
- Telemetria não documentada: o dispositivo envia dados para servidores estrangeiros sem o usuário saber. Em MI/IA, isso é um clássico — dados de treinamento, capturas de ambiente, padrões de uso.
- Backdoors em firmware: portas de manutenção escondidas, contas com senha hardcoded, JTAG/SWD expostos em produção.
- Canal de comando remoto: o robô pode ser convertido em ferramenta de ataque — desde um DDoS walker até um dispositivo de espionagem física.
Isso não é paranoia. Eu já vi, em auditorias de pen-test em dispositivos IoT, casos de portas Telnet abertas na rede interna de fábrica, contas com root:toor habilitadas e firmware assinado com chaves RSA de 1024 bits. Se um sensor de temperatura chinês barato fazia isso, imagine um robô com 20 sensores e dois processadores.
Na Prática: como checar se um dispositivo já está na Covered List da FCC
Se você está numa equipe comprando robôs, drones ou qualquer equipamento de RF para um projeto nos EUA, dá para cruzar a base da FCC direto no código. A FCC expõe uma API REST pública. Um script Python de 10 linhas resolve:
import requests
def check_fcc_covered(fcc_id: str) -> dict:
"""
Consulta o registro público da FCC a partir de um FCC ID.
Documentação: https://www.fcc.gov/oet/ea/fccid
"""
url = f"https://apps.fcc.gov/oetcf/eas/reports/GenericSearchResult.cfm?grantee_code={fcc_id[:3]}&product_code={fcc_id[3:]}"
headers = {"User-Agent": "dev-checker/1.0"}
resp = requests.get(url, headers=headers, timeout=15)
resp.raise_for_status()
return {
"fcc_id": fcc_id,
"status_code": resp.status_code,
"contains_covered": "covered list" in resp.text.lower(),
"raw_excerpt": resp.text[:500],
}
if __name__ == "__main__":
# Exemplo: trocar pelo FCC ID do equipamento que você está avaliando
result = check_fcc_covered("2AYX3-UNITREE-G1")
print(result)
Use isso no seu due diligence antes de fechar uma compra B2B. Não é infalível, mas já elimina os casos óbvios. A lista oficial também pode ser baixada direto em fcc.gov/supplychain/coveredlist.
Erros comuns que devs cometem nesse cenário
Na minha experiência, vejo três deslizes recorrentes:
1. Tratar o robô como “hardware burro” que só segue o ROS
Não é. O firmware proprietário roda paralelo à sua stack. Você não tem visibilidade de quais syscalls ele faz, quais conexões de rede ele abre em background, e nem sempre dá para desligar serviços no systemd embarcado. Antes de deploy, isole o robô numa VLAN separada e monitore o tráfego de saída nos primeiros 30 dias.
2. Ignorar a cadeia de firmware update
Se o fabricante tem acesso OTA para atualizar o firmware, em tese ele pode instalar binários no seu robô a qualquer momento. Em ambientes sensíveis (saúde, defesa, indústria crítica), isso é um vetor de risco inaceitável. Solução: hosts file travado, firewall outbound, e — quando possível — versão do firmware “fixada” com downgrade bloqueado.
3. Misturar fornecedor de hardware com fornecedor de modelo de IA
Cada elo da cadeia é uma superfície de ataque. Um robô chinês rodando um modelo de visão da OpenAI ou Anthropic ainda mantém o firmware chinês no controle do hardware. O ideal é rodar tudo em stack auditável: hardware (de preferência fora da lista negra), firmware open source (PX4, NuttX, Buildroot customizado), middleware (ROS 2), modelo (open weights) e telemetria sob seu controle.
4. Comprar robô sem cláusula de auditoria de segurança
Impossível auditar firmware proprietário via NDA. Se o fornecedor não deixa você inspecionar o sistema de arquivos embarcado, e não publica SBOM, considere isso um red flag. Não tem como blindar o que você não pode ver.
O que muda para o ecossistema open source de robótica
Tem um lado B que ninguém comenta: qualquer decisão desse tipo acaba acelerando movimentos open hardware. Projetos como o Open Dynamic Robot Initiative (Munich), o Stanford BDML com o A1, e iniciativas mais novas como o LeRobot da Hugging Face ganham tração porque passam a ser a única rota de stack totalmente auditável. Se você está começando um projeto de pesquisa ou produto agora, considere de cara montar com base open source — vai te salvar de uma reescrita daqui a dois anos.
Também vale lembrar: a medida é americana. Brasil, Europa e Ásia não estão (ainda) no mesmo caminho. Mas a tendência é se espalhar, e qualquer exportador de robôs para os EUA vai precisar repensar o pipeline de certificação.
FAQ — perguntas que devs me fazem sobre isso
1. A proibição da FCC atinge robôs que já estão no Brasil?
Não diretamente. A regra se aplica a equipamentos comercializados nos EUA. Mas fornecedores globais tendem a unificar linhas de produção, então o que começa como barreira americana vira restrição de fato no resto do mundo em 12-24 meses.
2. Robo vendidos pela Unitree, Fourier ou XPeng podem sumir do mercado?
Novos modelos, sim. Os já autorizados pela FCC continuam liberados. Mas a tendência é que os próximos lançamentos não passem pela aprovação condicional, especialmente se usarem chips de fabricantes sob suspeita.
3. Dá para usar um robô “blocked” só em ambiente de pesquisa, sem vender nos EUA?
Pode, dentro do ambiente universitário, respeitando as regras locais. Mas cuidado com licenciamento cruzado de fundação e a cláusula de “non-redistribution” — alguns fabricantes proíbem engenharia reversa.
4. NVIDIA Isaac ou Jetson estão na lista negra?
Não. A Covered List tem como alvo dispositivos finais. Mas se o seu robô usar Jetson mas o firmware do próprio robô vier de fornecedor bloqueado, o problema continua. Lembre que a cadeia inteira importa.
5. Qual é a alternativa real hoje para dev que quer montar humanoides sem travar?
Open source hardware quando existir (ex: Berkeley Humanoid Lite), ROS 2 + Isaac Lab para sim, e plataformas como Unitree ou Booster em modo de prototipagem — sabendo das implicações comerciais se for vender nos EUA.
Nota final
Esse movimento da FCC não é só política — é um sinal claro de que a próxima década de robótica vai ser disputada em três camadas: hardware, firmware e modelos de IA. Quem controlar as três vence. Quem não controlar nenhuma, consome. Como devs, a gente consegue auditar duas dessas três. Não é pouca coisa.
Se você está montando um stack de robótica, IoT ou IA embarcada, comece pelo checklist: fornecedor com SBOM? firmware auditável? rede segmentada? atualizações OTA sob seu controle? modelo on-device com fallback offline? Se a resposta for “não” em três dessas cinco, você tem um passivo de segurança esperando para explodir.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.