Neste artigo
Em 27 de agosto de 2026, uma ordem executiva dos Estados Unidos mudou o nome do lago Ontário para lago América no banco de dados federal de nomes geográficos. Três dias depois, o Google Maps aplicou a mudança, e o Apple Maps fez o mesmo em 2 de setembro. O Canadá rejeitou o nome, e a fronteira entre os dois países passa pelo próprio lago.
O resultado é que uma única entidade geográfica agora carrega três rótulos dependendo de onde se olha: quem está nos Estados Unidos vê lago América, quem está no Canadá vê lago Ontário e todos os demais veem os dois. Não é o primeiro caso; o golfo do México passou a se chamar golfo da América no ano passado, pela mesma lógica.
É fácil ler isso como notícia política e seguir em frente. O que realmente aconteceu foi um teste de engenharia: todo sistema no mundo que armazenou o nome desse lago como texto fixo agora mostra informação errada para uma parte dos seus usuários. A pergunta que nos interessa: o seu sistema foi construído para absorver esse tipo de mudança?
O erro de raiz: armazenar o rótulo em vez da identidade
A maioria dos sistemas armazena o que os olhos veem. Um campo de texto chamado cidade guarda Riad, um campo de país guarda o nome de um país, uma alíquota de imposto é um número escrito no código. Isso funciona com eficiência até que o próprio fato muda, e você descobre que os seus dados históricos já não podem ser interpretados.
A regra de engenharia é simples: armazene um identificador estável e gere o rótulo no momento da exibição. O lago é uma entidade com um identificador que não muda e vários nomes conforme o idioma, o contexto e a fonte oficial. Armazene o identificador, e uma mudança de nome vira uma atualização em uma tabela de referência. Armazene o nome, e ela vira um projeto completo de migração de dados.
O que realmente muda na vida de uma empresa saudita?
O lago é um exemplo distante. A lista não é:
- Alíquotas de impostos. O IVA saudita passou de 5% para 15% em 2020, e as empresas que tinham escrito o número no código tiveram uma semana difícil. Pior do que a mudança em si: as notas fiscais antigas precisam manter a alíquota antiga.
- Requisitos de faturamento eletrônico. As ondas de integração com a Autoridade de Zakat, Impostos e Alfândega (ZATCA) chegam em fases, e cada onda pode trazer uma mudança na especificação técnica.
- Nomes de países. Türkiye passou a ser o nome oficial na ONU em 2022, a Macedônia passou a ser Macedônia do Norte, a Suazilândia passou a ser Essuatíni. Qualquer lista de países digitada à mão no seu sistema já está desatualizada.
- Endereço nacional e formatos de dados. Os formatos de código postal, documento nacional de identidade, IBAN e número de registro da entidade são atualizados, e toda validação escrita como uma expressão regular rígida quebra na primeira ampliação.
- Impostos em outros mercados. Se você vende fora da Arábia Saudita, a mudança chega de países cujas notícias você não acompanha — como aconteceu este mês, quando as lojas de aplicativos adicionaram novos impostos em três países ao mesmo tempo.
Cinco princípios para uma infraestrutura que absorve mudanças
- Identificadores, não rótulos. Vincule cada entidade a um identificador estável e mantenha os nomes em uma tabela separada que aceite mais de um nome por entidade, por idioma e por fonte.
- Datas de vigência em todo valor que pode mudar. Uma alíquota de imposto não é um número, mas uma série de valores, cada um com data de início e de término. Só isso resolve a reimpressão de uma nota fiscal antiga com a alíquota correta e evita um desastre contábil na primeira auditoria.
- Dados de referência como configuração, não como código. Listas de países, moedas, impostos e regiões ficam em uma tabela ou em um arquivo de configuração que um administrador autorizado atualiza — não em constantes dentro do código que exigem uma nova versão e uma equipe de desenvolvimento.
- Uma camada de exibição separada do armazenamento. O que é armazenado é uma coisa; o que é exibido é outra. Quando um sistema separa as duas, mostrar nomes diferentes para usuários diferentes passa a ser uma configuração, e não uma reconstrução — exatamente o que o Google fez com o lago.
- Uma única fonte da verdade. Se a alíquota do imposto está escrita no banco de dados, no modelo da nota fiscal e no relatório de vendas, você tem três cópias que inevitavelmente vão divergir. Escolha um lugar e faça o resto ler a partir dele.
Uma verificação prática do seu sistema nesta semana
Isso não exige um projeto. Sente-se com o seu desenvolvedor e faça cinco perguntas:
- Se a alíquota do imposto mudasse amanhã, quantos arquivos teríamos de editar? E as notas fiscais antigas continuariam corretas?
- Onde fica a nossa lista de países e moedas — em uma tabela ou escrita no código?
- Armazenamos os nomes das cidades como texto ou como identificadores ligados a uma referência?
- O que acontece se a autoridade acrescentar um dígito ao documento nacional de identidade ou mudar o formato do código postal?
- Quantos lugares no sistema conhecem o valor do imposto? Se for mais de um, esse é o seu próximo problema.
As respostas expõem os seus pontos frágeis em meia hora, e a maioria deles se corrige em dias quando é tratada antes de ser necessária, e não depois.
A visão da Origami
Vemos aqui uma lição que repetimos aos clientes: um bom sistema não é o que funciona hoje, mas o que absorve um mundo em mudança sem ser reescrito. A diferença entre os dois não é a esperteza do programador, mas decisões de design simples tomadas na primeira semana: um identificador em vez de texto, uma data de vigência em vez de um número fixo, uma tabela de referência em vez de uma lista no código.
Essas decisões custam horas no início e economizam semanas depois. Já vimos empresas pararem de faturar por dias por causa de uma mudança regulatória que poderia ter sido absorvida com a atualização de uma única linha em uma tabela, e a causa é sempre a mesma: um valor escrito em um lugar que nunca foi projetado para mudar.
Conclusão
Um lago teve o nome mudado em um país e o novo nome rejeitado em outro, então agora carrega três rótulos ao mesmo tempo. Isso não é uma exceção; é uma miniatura do que acontece o tempo todo com os dados de referência. Impostos, nomes, formatos e regulamentações mudam por decisões externas que você não controla. O que você controla é a prontidão do seu sistema, e isso se decide no design, não no momento da mudança.
Fontes
- O blog oficial do Google — o comunicado sobre a aplicação da mudança de nome no Google Maps e como ela é exibida para os usuários nos Estados Unidos, no Canadá e no resto do mundo, 30 de agosto de 2026.
- A cobertura da Reuters, da TIME e da BBC sobre a ordem executiva de 27 de agosto de 2026, a mudança no Apple Maps em 2 de setembro e a posição do Canadá.
- Autoridade de Zakat, Impostos e Alfândega (ZATCA), zatca.gov.sa — a referência oficial para as alíquotas do IVA e as fases do faturamento eletrônico.
- As Nações Unidas — a adoção de Türkiye como nome oficial em 2022, como exemplo documentado de mudança de nome de país.
Perguntas frequentes
O que aconteceu com o nome do lago Ontário?
Uma ordem executiva dos Estados Unidos de 27 de agosto de 2026 mudou o nome para lago América no banco de dados federal de nomes geográficos. O Google Maps aplicou a mudança três dias depois e o Apple Maps em 2 de setembro, enquanto o Canadá rejeitou o nome.
Por que o nome varia conforme o país?
Porque o Google exibe os nomes de acordo com as fontes oficiais de cada país. Quem está nos Estados Unidos vê lago América, quem está no Canadá vê lago Ontário e todos os demais veem os dois nomes.
O que isso tem a ver com os sistemas de uma empresa?
Qualquer sistema que armazenou o nome como texto fixo agora mostra informação errada para parte dos seus usuários. A lição mais ampla é que os dados de referência — impostos, nomes de países, formatos de dados — mudam por decisão externa, e o seu sistema deve absorver isso sem ser reescrito.
Qual é o princípio mais importante?
Armazenar um identificador estável da entidade e gerar o rótulo no momento da exibição, em vez de armazenar o próprio nome. Assim, uma mudança de nome vira uma atualização em uma única tabela de referência, e não um projeto de migração de dados.
Como devo lidar com uma mudança na alíquota do imposto?
Trate a alíquota como uma série de valores, cada um com data de início e de término, e não como um número único. Isso mantém as notas fiscais antigas com a alíquota correta quando forem reimpressas ou auditadas.
Como sei se o meu sistema é frágil?
Pergunte ao seu desenvolvedor: quantos arquivos mudam se a alíquota do imposto mudar amanhã? Onde fica a lista de países e moedas? Quantos lugares conhecem o valor do imposto? Vários lugares é o primeiro sinal de fragilidade.
Siga a Origami no Google
Adicione a Origami como fonte preferida e os nossos artigos aparecerão primeiro para você na Pesquisa Google e nas principais notícias.








