A autorização para testar um carro autónomo não significa que ele possa circular em qualquer rua, sob qualquer condição. O ponto central da notícia é outro: a China está permitindo que empresas validem operações reais dentro de limites definidos — e isso transforma a condução autónoma num problema de engenharia de sistemas, não apenas de inteligência artificial.
Segundo o Sapo.pt, a Xpeng recebeu autorização para operações de demonstração dos robotáxis Yoyo em Guangzhou, enquanto a Volkswagen obteve licença para testes de condução autónoma de nível 3 em Hefei. São permissões diferentes, para tecnologias e cenários diferentes. Para quem desenvolve software, essa distinção importa tanto quanto o modelo de IA usado no veículo.
O que as licenças da Xpeng e da Volkswagen permitem
A licença da Xpeng abre caminho para testar operações com os robotáxis Yoyo em Guangzhou. A experiência pode incluir transporte de passageiros mediante cobrança, mas isso não equivale a uma licença comercial definitiva. O acesso gradual por códigos de convite permite controlar a exposição inicial e observar como o serviço se comporta na rua.
A Volkswagen, por sua vez, recebeu autorização para testar condução autónoma de nível 3 em Hefei, por meio da Volkswagen (Anhui) Automotive Company, uma joint venture com a JAC. Não é correto tratar as duas autorizações como se fossem versões equivalentes do mesmo programa: a Xpeng está associada a robotáxis de nível 4; a Volkswagen, a testes de nível 3.
Guangzhou já reúne outras empresas e grupos autorizados a operar ou testar tecnologias autónomas, incluindo Pony.ai, WeRide, Baidu e Guangzhou Automobile Group. Essa concentração cria um ambiente útil para comparar operações, mas também aumenta a importância de regras claras para dados, segurança e interação com o trânsito convencional.
Nível 3 e nível 4: a diferença que muda o software
Os níveis de automação são uma forma de descrever quem executa a tarefa de condução e quem precisa responder quando o sistema não consegue continuar. Eles não medem diretamente a qualidade de uma empresa nem garantem que um veículo seja seguro em todos os cenários.
No nível 3, o sistema pode conduzir em determinadas condições, mas o utilizador precisa estar preparado para assumir o controlo quando solicitado. Isso cria um desafio de interface e de segurança: o veículo precisa detectar que está prestes a sair do seu domínio operacional e dar tempo suficiente para a pessoa reagir.
No nível 4, o sistema pode executar a condução sem intervenção humana dentro de uma área e de condições operacionais previamente delimitadas. Isso não significa autonomia universal. Fora do domínio operacional — frequentemente chamado de ODD, de Operational Design Domain — o sistema não deve simplesmente continuar como se nada tivesse mudado.
Na prática, o ODD pode limitar uma operação a certas ruas, velocidades, condições meteorológicas ou horários. Essa fronteira precisa ser tratada como uma regra explícita do produto. Um modelo de percepção com bom desempenho médio não compensa uma decisão errada sobre quando o veículo está fora das condições autorizadas.
Robotáxi é um sistema distribuído, não só um carro com IA
Quando penso numa frota autónoma, vejo vários serviços trabalhando juntos: sensores e computação embarcada, localização, planeamento de rota, gestão da frota, telemetria, apoio remoto e sistemas de segurança. A decisão crítica acontece no veículo, mas a operação comercial depende também de software fora dele.
Essa arquitetura traz problemas familiares para quem desenvolve sistemas distribuídos. A conectividade pode cair, eventos podem chegar atrasados e serviços externos podem ficar indisponíveis. Por isso, o veículo não pode depender de uma resposta da nuvem para cada decisão de condução. A rede pode ajudar a coordenar uma frota; não deve ser tratada como substituta do controlo local seguro.
Também é preciso separar observabilidade de controlo. Telemetria ajuda a entender o que aconteceu e a melhorar operações, mas não deve abrir uma via para enviar comandos inseguros ao veículo. Ações remotas precisam de autorização, registos auditáveis e limites claros, além de comportamento definido para perda de comunicação.
Por que testar com passageiros muda a engenharia
Uma demonstração em via pública testa muito mais do que a capacidade de seguir uma rota. O sistema precisa conviver com obras, veículos mal estacionados, pedestres imprevisíveis, mudanças de sinalização e situações que não aparecem com a mesma frequência em simulações.
Com passageiros, entram requisitos de produto e operação: embarque e desembarque, comunicação de incidentes, acessibilidade, limpeza, gestão de solicitações e suporte ao utilizador. O código pode estar correto segundo os testes unitários e, ainda assim, a experiência falhar porque o passageiro não sabe o que fazer quando o veículo para ou altera o percurso.
A Xpeng afirma que a experiência deve ajudar a aperfeiçoar processos e criar soluções para parceiros internacionais. A empresa também conversa com plataformas europeias de transporte, segundo a notícia. A expansão, porém, não é uma simples troca de idioma na aplicação: regras de circulação, mapas, dados, seguros e expectativas dos utilizadores variam entre mercados.
Na Prática: validar se uma viagem está dentro do ODD
Uma forma útil de pensar na autorização é tratar o ODD como uma política verificável. O exemplo abaixo não controla um veículo e não representa o software da Xpeng ou da Volkswagen. Ele mostra como um serviço de despacho poderia recusar uma solicitação quando condições básicas da operação não são atendidas.
O motivo para validar antes de despachar é simples: não adianta aceitar uma viagem e descobrir depois que o destino fica fora da área permitida ou que as condições excedem os limites configurados. Em produção, a definição do ODD teria de vir de requisitos de segurança e homologação, não de valores escolhidos por conveniência.
from dataclasses import dataclass
@dataclass(frozen=True)
class TripRequest:
pickup_zone: str
dropoff_zone: str
requested_speed_kmh: int
raining_heavily: bool
@dataclass(frozen=True)
class ODDPolicy:
allowed_zones: frozenset[str]
max_speed_kmh: int
heavy_rain_allowed: bool = False
def is_trip_eligible(request: TripRequest, policy: ODDPolicy) -> tuple[bool, str]:
if request.pickup_zone not in policy.allowed_zones:
return False, "Origem fora da área operacional"
if request.dropoff_zone not in policy.allowed_zones:
return False, "Destino fora da área operacional"
if request.requested_speed_kmh > policy.max_speed_kmh:
return False, "Velocidade solicitada acima do limite configurado"
if request.raining_heavily and not policy.heavy_rain_allowed:
return False, "Condição meteorológica fora do ODD"
return True, "Viagem elegível para despacho"
policy = ODDPolicy(
allowed_zones=frozenset({"centro", "distrito-norte"}),
max_speed_kmh=50,
)
trip = TripRequest(
pickup_zone="centro",
dropoff_zone="distrito-norte",
requested_speed_kmh=40,
raining_heavily=False,
)
print(is_trip_eligible(trip, policy))Esse tipo de validação precisa ser complementado por testes de fronteira: zona desconhecida, destino alterado durante a viagem, dados meteorológicos desatualizados e falha ao consultar um serviço. Para uma função que decide se uma viagem pode começar, eu prefiro falhar de forma segura: se a política não puder ser confirmada, não despacho o veículo automaticamente.
Erros comuns ao desenvolver sistemas para condução autónoma
- Confundir licença de teste com autorização comercial. Uma permissão de demonstração não prova que o serviço está liberado para operação ampla. É preciso acompanhar o escopo exato da autorização.
- Tratar nível 4 como autonomia em qualquer lugar. O sistema só deve operar dentro do ODD validado. A fronteira precisa estar representada no software e ser testada.
- Usar a nuvem como requisito para decisões críticas. Se a conectividade cair, o veículo precisa continuar a gerir a situação localmente e entrar num estado seguro, conforme os requisitos do sistema.
- Medir sucesso apenas pela taxa de viagens concluídas. Também importam intervenções, quase acidentes, paragens inesperadas, falhas de comunicação e comportamento em cenários raros.
- Testar só o caminho feliz. Simulação, testes de integração e testes em campo precisam incluir sensores indisponíveis, mapas inconsistentes, alterações de rota e eventos inesperados.
- Ignorar privacidade e segurança operacional. Dados de localização e imagem podem ser sensíveis. A recolha precisa ter finalidade definida, controlo de acesso, retenção limitada e proteção contra alterações indevidas.
O que isso significa para quem programa
Para desenvolvedores, a lição mais prática é que sistemas autónomos exigem decisões explícitas sobre limites, falhas e responsabilidade. O mesmo princípio vale para software de pagamentos, dispositivos médicos e plataformas industriais: a funcionalidade principal é apenas uma parte do produto; os estados de erro definem se ele é confiável.
Também vale evitar a armadilha de achar que o desafio se resolve escolhendo um modelo maior. Percepção, localização e planeamento dependem de dados e validação, mas a operação depende de integração, testes, monitorização e processos humanos. Uma melhoria no modelo pode reduzir certos erros sem resolver problemas de despacho, manutenção ou suporte ao passageiro.
O mercado de condução autónoma é apontado na notícia como uma oportunidade que poderá chegar a um bilião de dólares até 2040. Mesmo que a projeção se concretize, a adoção dependerá de mais do que avanços em IA: será preciso demonstrar segurança, viabilidade económica e capacidade de operar em cidades reais.
Perguntas frequentes
O que significa a licença recebida pela Xpeng em Guangzhou?
Ela permite operações de demonstração dos robotáxis Yoyo na cidade. A autorização pode viabilizar serviços com passageiros, mas não deve ser confundida com uma licença comercial definitiva.
Qual é a diferença entre condução autónoma L3 e L4?
No nível 3, o utilizador deve estar preparado para assumir o controlo quando o sistema solicitar. No nível 4, o veículo pode conduzir sem intervenção humana dentro de um domínio operacional definido, mas não necessariamente fora dele.
Por que a Volkswagen está a testar numa cidade diferente?
A autorização citada para a Volkswagen é para testes de nível 3 em Hefei, na província de Anhui, através da joint venture Volkswagen (Anhui) Automotive Company. A notícia não indica que o programa seja o mesmo da operação de robotáxis da Xpeng em Guangzhou.
Um robotáxi L4 pode circular em qualquer estrada?
Não. L4 não significa capacidade irrestrita. A operação depende de um ODD, que pode limitar áreas, condições e outros parâmetros definidos para o sistema.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.