En este artículo
El 27 de agosto de 2026, una orden ejecutiva de Estados Unidos cambió el nombre del lago Ontario por el de lago América en la base de datos federal de nombres geográficos. Tres días después, Google Maps aplicó el cambio, y Apple Maps lo siguió el 2 de septiembre. Canadá rechazó el nombre, y la frontera entre ambos países atraviesa el propio lago.
El resultado es que una sola entidad geográfica lleva ahora tres etiquetas según desde dónde se mire: en Estados Unidos se ve lago América, en Canadá se ve lago Ontario y en el resto del mundo se ven ambas. No es el primer caso: el golfo de México pasó a llamarse golfo de América el año pasado con la misma lógica.
Es fácil leer esto como una noticia política y pasar página. Lo que realmente ocurrió es una prueba de ingeniería: todos los sistemas del mundo que guardaron el nombre de este lago como texto fijo muestran ahora información errónea a una parte de sus usuarios. La pregunta que nos importa: ¿está tu sistema construido para absorber ese tipo de cambio?
El error de fondo: guardar la etiqueta en lugar de la identidad
La mayoría de los sistemas guardan lo que ve el ojo. Un campo de texto llamado ciudad contiene Riad, un campo de país contiene el nombre de un país, un tipo impositivo es un número escrito en el código. Eso funciona con eficacia hasta que el propio hecho cambia y descubres que tus datos históricos ya no se pueden interpretar.
La regla de ingeniería es sencilla: guarda un identificador estable y genera la etiqueta en el momento de mostrarla. El lago es una entidad con un identificador que no cambia y varios nombres según el idioma, el contexto y la fuente oficial. Si guardas el identificador, un cambio de nombre se convierte en una actualización de una tabla de referencia. Si guardas el nombre, se convierte en un proyecto completo de migración de datos.
¿Qué cambia realmente en la vida de una empresa saudí?
El lago es un ejemplo lejano. La lista no lo es:
- Tipos impositivos. El IVA saudí pasó del 5% al 15% en 2020, y las empresas que habían escrito el número en su código pasaron una semana difícil. Peor que el cambio en sí: las facturas antiguas deben conservar su tipo antiguo.
- Requisitos de facturación electrónica. Las oleadas de integración con la Autoridad de Zakat, Impuestos y Aduanas (ZATCA) llegan por fases, y cada oleada puede traer un cambio en la especificación técnica.
- Nombres de países. Türkiye pasó a ser el nombre oficial ante la ONU en 2022, Macedonia pasó a ser Macedonia del Norte, Suazilandia pasó a ser Esuatini. Cualquier lista de países escrita a mano en tu sistema ya está desactualizada.
- Dirección nacional y formatos de datos. Los formatos del código postal, el documento nacional de identidad, el IBAN y el número de entidad se actualizan, y toda validación escrita como una expresión regular rígida se rompe en la primera ampliación.
- Impuestos en otros mercados. Si vendes fuera de Arabia Saudí, el cambio llega desde países cuyas noticias no sigues, como ocurrió este mes cuando las tiendas de aplicaciones añadieron nuevos impuestos en tres países a la vez.
Cinco principios para una infraestructura que absorbe el cambio
- Identificadores, no etiquetas. Vincula cada entidad a un identificador estable y guarda los nombres en una tabla aparte que acepte más de un nombre por entidad, por idioma y por fuente.
- Fechas de vigencia en cada valor que pueda cambiar. Un tipo impositivo no es un número, sino una serie de valores, cada uno con fecha de inicio y de fin. Solo esto resuelve la reimpresión de una factura antigua con el tipo correcto y evita un desastre contable en la primera auditoría.
- Datos de referencia como configuración, no como código. Las listas de países, monedas, impuestos y regiones viven en una tabla o en un archivo de configuración que actualiza un administrador autorizado, no en constantes dentro del código que necesitan una nueva versión y un equipo de desarrollo.
- Una capa de presentación separada del almacenamiento. Lo que se guarda es una cosa; lo que se muestra es otra. Cuando un sistema las separa, mostrar nombres distintos a usuarios distintos es un ajuste y no una reconstrucción, que es exactamente lo que hizo Google con el lago.
- Una única fuente de verdad. Si el tipo impositivo está escrito en la base de datos, en la plantilla de factura y en el informe de ventas, tienes tres copias que inevitablemente acabarán discrepando. Elige un solo lugar y haz que el resto lea de él.
Una revisión práctica de tu sistema esta semana
Esto no necesita un proyecto. Siéntate con tu desarrollador y hazle cinco preguntas:
- Si el tipo impositivo cambiara mañana, ¿cuántos archivos tendríamos que editar? ¿Y las facturas antiguas seguirían siendo correctas?
- ¿Dónde está nuestra lista de países y monedas: en una tabla o escrita en el código?
- ¿Guardamos los nombres de las ciudades como texto o como identificadores vinculados a una referencia?
- ¿Qué pasa si la autoridad añade un dígito al documento nacional de identidad o cambia el formato del código postal?
- ¿Cuántos lugares del sistema conocen el valor del impuesto? Si son más de uno, ese es tu próximo problema.
Las respuestas dejan al descubierto tus puntos frágiles en media hora, y la mayoría se corrigen en días cuando se abordan antes de que hagan falta y no después.
La visión de Origami
Vemos aquí una lección que repetimos a nuestros clientes: un buen sistema no es el que funciona hoy, sino el que absorbe un mundo cambiante sin tener que reescribirse. La diferencia entre ambos no es la habilidad del programador, sino decisiones de diseño sencillas tomadas en la primera semana: un identificador en lugar de texto, una fecha de vigencia en lugar de un número fijo, una tabla de referencia en lugar de una lista en el código.
Esas decisiones cuestan horas al principio y ahorran semanas después. Hemos visto empresas dejar de facturar durante días por un cambio normativo que podría haberse absorbido actualizando una sola fila de una tabla, y la causa es siempre la misma: un valor escrito en un lugar que nunca se diseñó para que cambiara.
Conclusión
Un lago cambió de nombre en un país y el nombre fue rechazado en otro, así que ahora lleva tres etiquetas a la vez. No es una excepción; es una miniatura de lo que les ocurre constantemente a los datos de referencia. Impuestos, nombres, formatos y normativas cambian por decisiones externas que no controlas. Lo que sí controlas es la preparación de tu sistema, y eso se decide en el diseño, no en el momento del cambio.
Fuentes
- El blog oficial de Google: el comunicado sobre la aplicación del cambio de nombre en Google Maps y cómo se muestra a los usuarios en Estados Unidos, Canadá y el resto del mundo, 30 de agosto de 2026.
- La cobertura de Reuters, TIME y la BBC sobre la orden ejecutiva del 27 de agosto de 2026, el cambio en Apple Maps del 2 de septiembre y la postura de Canadá.
- Autoridad de Zakat, Impuestos y Aduanas (ZATCA), zatca.gov.sa: la referencia oficial para los tipos de IVA y las fases de la facturación electrónica.
- Las Naciones Unidas: la adopción de Türkiye como nombre oficial en 2022, como ejemplo documentado de cambio de nombre de un país.
Preguntas frecuentes
¿Qué pasó con el nombre del lago Ontario?
Una orden ejecutiva de Estados Unidos del 27 de agosto de 2026 lo cambió a lago América en la base de datos federal de nombres geográficos. Google Maps aplicó el cambio tres días después y Apple Maps el 2 de septiembre, mientras que Canadá rechazó el nombre.
¿Por qué el nombre cambia según el país?
Porque Google muestra los nombres según las fuentes oficiales de cada país. En Estados Unidos se ve lago América, en Canadá se ve lago Ontario y en el resto del mundo se ven ambos nombres.
¿Qué tiene que ver esto con los sistemas de una empresa?
Cualquier sistema que guardó el nombre como texto fijo muestra ahora información errónea a una parte de sus usuarios. La lección más amplia es que los datos de referencia —impuestos, nombres de países, formatos de datos— cambian por decisión externa, y tu sistema debería absorberlo sin reescribirse.
¿Cuál es el principio más importante?
Guardar un identificador estable de la entidad y generar la etiqueta en el momento de mostrarla, en lugar de guardar el propio nombre. Así, un cambio de nombre se convierte en una actualización de una sola tabla de referencia y no en un proyecto de migración de datos.
¿Cómo debo gestionar un cambio en el tipo impositivo?
Trata el tipo como una serie de valores, cada uno con fecha de inicio y de fin, y no como un único número. Así las facturas antiguas conservan su tipo correcto cuando se reimprimen o se auditan.
¿Cómo sé si mi sistema es frágil?
Pregunta a tu desarrollador: ¿cuántos archivos cambian si el tipo impositivo cambia mañana? ¿Dónde está la lista de países y monedas? ¿Cuántos lugares conocen el valor del impuesto? Que sean varios lugares es la primera señal de fragilidad.
Sigue a Origami en Google
Añade Origami como fuente preferida y nuestros artículos te aparecerán primero en la Búsqueda de Google y en las Noticias destacadas.








