El 24 de septiembre de 2026, Japón renovó a gran escala su sistema tributario nacional. Nada más hacerlo, las ventanillas de las oficinas de impuestos empezaron a tardar "bastante" en cobrar en efectivo o emitir certificados de pago de impuestos, y el portal de declaración electrónica e-Tax sufrió varios fallos y paradas de emergencia. Que un sistema enorme e integrado se vuelva inestable justo después del cambio lo entiende bien cualquiera que haya trabajado con sistemas distribuidos o automatizado procesos. Pero "entender que se rompa" y "tener una salida de emergencia suficiente cuando se rompe" son cosas muy distintas.
Imagina que tienes un trámite urgente y en la ventanilla te dicen: "El sistema entero está fallando y todavía no sabemos cuándo se arregla. Si es urgente, venga en persona y lo atendemos".
Lo normal es pensar: "Pues voy y ya".
Pero si lo piensas un poco más, el panorama se pone feo.
La gente que no puede resolver su trámite por internet ni por la vía habitual acaba en la ventanilla. Mientras tanto, el personal tiene un sistema inestable y cada gestión le lleva más tiempo. Llega más gente, pero la capacidad de atención baja.
"Venga y lo atendemos" no es lo mismo que "venga y se lo resolvemos en un santiamén".
Así que, si tu plazo no es inminente, esperar es una decisión bastante razonable.
Y por dentro dan ganas de gritar:
"Que reciban los papeles en papel ya, en serio".
Eso sí, el papel no es una base de datos de respaldo mágica.
1. Qué pasó en septiembre de 2026
La Agencia Tributaria Nacional de Japón (NTA) renovó su sistema el 24 de septiembre de 2026. Sobre el sistema de nueva generación, KSK2, la NTA llevaba tiempo planteando tres ideas de diseño:
- Pasar de trabajar con documentos en papel a tramitar con datos como eje
- Unificar las bases de datos y aplicaciones que antes estaban separadas por tipo de impuesto
- Cambiar los grandes ordenadores centrales con sistema operativo propietario por sistemas abiertos con sistemas operativos de uso general
Es decir, no se trata de un simple lavado de cara de las pantallas. Cambia a la vez la forma de guardar los datos, las fronteras entre aplicaciones y la propia infraestructura.
El mismo 24 de septiembre, día de la renovación, la NTA publicó un aviso sobre "retrasos en los trámites en las ventanillas de las oficinas de impuestos". Explicaba que el cobro en efectivo, la emisión de certificados de pago de impuestos y otros trámites requerían bastante tiempo, y que ni siquiera pidiéndolos por e-Tax se emitían al instante. La renovación se había completado, pero había problemas con el funcionamiento de los sistemas que necesita la atención en ventanilla.
Esa misma semana de transición también hubo fallos al iniciar sesión mediante Mynaportal (el portal de trámites públicos de Japón ligado a la tarjeta de número personal), errores en la pantalla de confirmación de pagos por banca en línea, la suspensión de algunas funciones de e-Tax y paradas de emergencia para atender las incidencias. La suspensión de esas funciones de e-Tax se anunció como resuelta antes del 27 de septiembre.
Por otro lado, el aviso sobre los retrasos en ventanilla seguía publicado el 28 de septiembre como información urgente en la web de la NTA. En ese momento no se había hecho pública la causa de fondo.
Y hay algo todavía más importante: no hay que confundir el mantenimiento programado con las averías. En esta renovación ya estaban previstos un corte largo desde las 0:00 del 19 de septiembre hasta las 8:30 del día 24, y otro de todo el día 26. A eso se sumaron los fallos posteriores al cambio y el mantenimiento de emergencia.
Por eso es normal tener la sensación de "¿no estará todo el rato parado?", aunque en esa sensación se mezclan paradas planificadas y paradas por avería.
2. Hasta un sistema serio que maneja dinero falla. De hecho, a veces se detiene precisamente por eso
"Si es un sistema de impuestos y dinero, ¿no lo harán para que no se pare jamás?"
Por intuición, sí.
Pero en los sistemas críticos, además de la disponibilidad, existe la consistencia.
Por ejemplo, lo más temible en un proceso de pago no es que una pantalla tarde cinco minutos en abrirse.
- Que hayas pagado y figures como moroso
- Que una misma operación se registre dos veces
- Que se emita un certificado con datos desactualizados
- Que se actualice un sistema y el otro se quede atrás
- Que al reintentar tras la recuperación se vuelva a ejecutar la misma operación
En ese estado, "lo dejamos funcionando como fuera" puede ser más peligroso que parar.
Los materiales de SRE (ingeniería de fiabilidad de sitios) de Google también explican que, ante una avería grave, conviene frenar el daño antes de buscar la causa raíz, y que si existe riesgo de corrupción de datos puede ser mejor congelar el sistema.
No es que se pare a pesar de que haya dinero de por medio.
Es que, al haber dinero de por medio, a veces hay que parar en lugar de seguir funcionando sin poder garantizar un estado correcto.
Si "¿has probado a reiniciar?" lo arreglara todo, los responsables de los sistemas centrales de todo el país saldrían mucho antes del trabajo.
3. Aunque pasen todas las pruebas unitarias, al integrar explota igual
Lo peor de los sistemas integrados es que pueden romperse en conjunto aunque cada pieza esté bien.
El sistema A funciona.
El sistema B también.
La base de datos, bien.
La autenticación, también.
Y aun así, si el formato que pasa de A a B difiere en un solo carácter, todo se detiene.
Si los datos migrados del sistema antiguo al nuevo tienen un valor atípico, se detiene.
Si en mitad de un reintento se pierde solo la respuesta, ya no sabes si la operación se procesó o no.
Cachés viejas, formularios viejos, conexiones con organismos externos, permisos, horas, procesos por lotes, codificación de caracteres, caracteres antiguos, reenvíos tras una avería. Cuantas más fronteras hay, más combinaciones aparecen que no se veían por separado.
Incluso una pequeña automatización personal falla con facilidad por estados antiguos, ejecuciones duplicadas, omisiones, diferencias en APIs externas o efectos secundarios de los reintentos.
Ahora imagina hacer eso en un sistema central que abarca las oficinas de todo el país, varios impuestos, cobros, devoluciones, certificados, e-Tax y organismos externos.
Quien sabe lo difícil que es integrar piensa: "bueno, justo después del cambio algo sale siempre".
Pero eso no es una carta blanca.
Lo que hay que valorar no es solo si no hubo ni un fallo, sino hasta qué punto se pudo reducir el servicio de forma segura cuando los hubo.
4. Por qué se llega a "no hay fecha prevista de recuperación"
Para el usuario, esta es de las frases más frustrantes:
"La fecha de recuperación está por determinar".
Pero prometer una hora cualquiera cuando aún no se conoce la causa puede ser más peligroso.
Recuperar un sistema crítico no consiste en volver a encender el servidor y listo.
Primero se delimita el alcance de la avería.
Luego se comprueba que los datos no se hayan escrito a medias.
Se verifica que volver a ejecutar no provoque un procesamiento duplicado.
Se revisa que el estado no sea incoherente con los sistemas externos conectados.
Si hace falta, se estudia volver atrás o usar una vía alternativa.
Tras la recuperación, se van procesando por orden las operaciones acumuladas durante la parada y se concilian los resultados.
Sobre todo es un problema cuando se mezclan casos como "el emisor ve que salió bien, pero el receptor no lo ha confirmado".
En un texto sobre diseño de sistemas distribuidos publicado por Amazon también se explica que, para que los reintentos sean seguros, es clave la idempotencia: que reenviar la misma petición no duplique sus efectos.
No dar una hora de recuperación no demuestra que los responsables no estén haciendo nada.
Si no se sabe hasta dónde llega el daño, hasta dónde se puede volver atrás y desde dónde reanudar sin duplicar procesos, hacer una previsión precisa es difícil de por sí.
5. "Si es urgente, venga a la ventanilla": como cola de espera, da bastante miedo
Aquí entra la ventanilla.
Incluso con el sistema averiado, a veces se dice "si viene en persona, se lo atendemos".
Es una salida de emergencia de agradecer.
Pero, desde el punto de vista del tiempo de espera, se juntan condiciones muy peligrosas.
Simplifiquemos el funcionamiento normal.
Llamemos λ a la cantidad de gente que llega a la ventanilla y μ a la cantidad que el personal puede atender.
Cuando hay una avería, pueden ocurrir dos cosas a la vez.
Primero, llega a la ventanilla incluso gente que normalmente resolvería su trámite por internet o por procesos internos, así que λ sube.
Segundo, al personal le cuesta más usar el sistema y cada gestión requiere más comprobaciones o entrada manual de datos, así que μ baja.
Sube la demanda y baja la capacidad de atención.
Para una cola, es la peor combinación.
Y el personal de las oficinas de impuestos no se multiplica solo cuando ocurre una avería.
Los materiales de SRE de Google también señalan que, al acercarse a la sobrecarga, un sistema no se limita a ir un poco más lento: puede empeorar de forma no lineal por el aumento de las esperas y los fallos en cadena. Por eso son importantes el control de carga y las respuestas con servicio reducido.
"Si viene a la ventanilla, se le atiende" no significa que la ventanilla esté vacía.
Si tu plazo tiene margen, no lanzarte justo en el pico de la avería y esperar a la recuperación es una decisión bien razonable si cuentas el coste en tiempo.
En cambio, si hay un plazo legal o algo urgente de por medio, no lo dejes pasar por tu cuenta: consulta los avisos oficiales de la NTA o de la oficina de impuestos de ese momento para ver qué alternativas hay.
6. "Que lo hagan en papel" es medio cierto. El papel sirve de salida para recibir trámites, pero no es una base de datos de respaldo
Viendo estas averías, uno empieza a pensar:
"Pues que reciban todo en papel y ya".
La idea no es del todo errónea.
La guía de planificación de continuidad de sistemas de información del NIST (el instituto de normas de Estados Unidos) también incluye, como forma alternativa de operar durante una avería, realizar a mano parte o la totalidad de los procesos de negocio durante un tiempo corto.
Es decir, el trabajo manual es una medida de continuidad más, y legítima.
Pero eso no significa que "escribirlo en papel lo resuelva todo".
Lo que se puede hacer en papel es, por ejemplo, esto:
- Dejar constancia de que se recibió una solicitud o consulta
- Fijar la fecha y hora de recepción
- Quedarse con los documentos necesarios
- Establecer un orden para tramitar todo tras la recuperación
- Entregar un número de consulta o un resguardo
En cambio, la verificación de datos centrales, la comprobación del estado de los pagos, la consulta de registros anteriores, la emisión exacta de certificados o la conexión con organismos externos pueden no poder completarse sin el sistema central.
Por eso, lo ideal no es "volver todo al papel".
Es que, aunque se caiga el sistema central, no se caiga también la recepción.
El papel no es una base de datos de respaldo.
Pero un resguardo de recepción en papel sí puede ser una salida de emergencia.
7. Lo que de verdad hace falta es una "operación reducida" que no se detenga del todo
Un sistema resistente a las averías no siempre mantiene el 100 % de sus funciones.
Más bien conserva las funciones esenciales y pasa a un modo simplificado.
Google SRE lo trata como degradación gradual de funciones, lo que se conoce como graceful degradation. El NIST también menciona instalaciones alternativas, sedes alternativas y procesos manuales como opciones de un plan de continuidad.
Aplicado a los trámites tributarios, el modelo ideal sería algo así:
- No parar la recepción. Poder recoger al menos los datos básicos de la solicitud, sin conexión o en papel.
- Emitir un número de recepción. Acabar con el "no sé si lo han recibido".
- Meterlo en una cola de procesamiento posterior. Poder reprocesarlo en orden tras la recuperación.
- Evitar el procesamiento duplicado. Tener un identificador que haga que una misma solicitud, aunque se vuelva a introducir, cuente como una sola.
- Distinguir la urgencia. Dar prioridad a lo que tiene plazo o mucho impacto en la vida de la gente.
- Mostrar el estado a los usuarios. Informar por separado de qué está parado, qué se puede usar y qué ya se ha recuperado.
- Conciliar tras la recuperación. Cotejar lo recibido en papel o sin conexión con los datos de producción para detectar omisiones y duplicados.
Lo importante no es la ilusión de que "aunque haya una avería, todo siga igual".
Es diseñar cómo se rompe.
8. Entonces, ¿con qué frecuencia falla e-Tax?
Si se revisan los avisos oficiales de e-Tax de 2026, se ven varios anuncios de incidencias a lo largo del año: en enero, retraso en la notificación de pago completado; en febrero, fallos de conexión con Mynaportal y dificultades para iniciar sesión; en marzo, dificultades para iniciar sesión; en julio, fallos al usar Mynaportal; en agosto, imposibilidad de usar el pago directo y otras funciones; y en septiembre, varios fallos justo después de la renovación.
Pero aquí no se puede contar a la ligera.
No son todos la misma avería.
Hay problemas del propio e-Tax, de la conexión con Mynaportal, de los pagos, de la visualización y de servicios externos. Además, el mantenimiento programado no es una avería.
Por eso, lo único que se puede decir a partir de la lista oficial es que "se anuncian varias veces al año fallos parciales y averías en las conexiones periféricas", y no que "el sistema tributario entero se cae por todo el país a cada rato".
Lo de septiembre de 2026 llama la atención sobre todo porque, en la semana de transición de una renovación enorme, se juntaron una parada planificada larga y varios fallos posteriores al cambio.
9. Cuando conoces el infierno de la integración, tu enfado cambia un poco
Quien ha construido alguna vez un pequeño sistema automatizado mira de otra manera las averías de los grandes sistemas.
Antes, la reacción era:
"¿Cómo puede ser que esto se pare?"
Y ahí acababa todo.
Pero una vez que has conectado varios servicios, usado colas, añadido reintentos, guardado estados y enlazado con APIs externas, aparece también otra reacción:
"Uf, un cambio de sistema integrado. Eso es un infierno".
Por separado todo funciona, pero en conjunto se rompe.
Arreglas algo y se rompe otra frontera.
Quedan estados antiguos.
Reintentas y se duplica.
Miras el registro y era información de ayer.
Con haber vivido aunque sea una versión pequeña de eso, es más fácil imaginar lo difícil que es un sistema central enorme.
Pero entender no es lo mismo que valorar.
En lugar de zanjarlo con un "es difícil, no hay nada que hacer", conviene fijarse en lo siguiente:
- Hasta dónde se hicieron pruebas de carga y de migración antes del cambio
- Hasta dónde se pudo operar con servicio reducido durante la avería
- Hasta dónde funcionó la recepción manual
- Si los avisos de estado fueron suficientes para los usuarios
- Si se publicarán la causa y las medidas para que no se repita tras la recuperación
- Si en el próximo cambio se podrá evitar el mismo tipo de accidente
Por complejo que sea, los accidentes pueden ocurrir.
Precisamente por ser complejo, importan el diseño y el aprendizaje posteriores al accidente.
10. Conclusión: no es "que lo hagan todo en papel", sino "que la puerta de entrada no muera, ni que sea en papel"
Cuando se para el sistema central de una oficina de impuestos, para el usuario resulta bastante injusto.
Es un lugar que maneja dinero y trámites legales, y aun así se para.
Ni siquiera se sabe cuándo se recuperará.
Dicen que se puede ir a la ventanilla, pero es evidente que estará llena.
Y entonces dan ganas de decir "que lo hagan en papel".
Dentro de esa sensación hay una exigencia de diseño bastante importante.
Sustituir todo el sistema tributario solo con papel no es realista.
Pero tampoco hace falta que, en cuanto el sistema se cae, mueran con él la recepción, el registro, la priorización y la cola de procesamiento posterior.
Lo que necesita un sistema enorme no es el mito de que "nunca se romperá".
Es que, aunque se rompa, quede al menos el trabajo mínimo.
Que se pueda volver atrás sin procesar nada dos veces.
Que se informe a los usuarios de qué funciona y qué no.
Y que, tras la recuperación, se pueda recuperar con seguridad el trabajo que quedó parado.
En resumen, la exigencia final es esta:
No es "que lo hagan todo en papel".
Es "que al menos la recepción se pueda levantar en papel. En serio".
- Agencia Tributaria Nacional (NTA), "Sobre los retrasos en los trámites en las ventanillas de las oficinas de impuestos", 2026-09-24
https://www.nta.go.jp/files/000041014.pdf - NTA, "Sobre la renovación del sistema tributario nacional"
https://www.nta.go.jp/taxes/shiraberu/sodan/system.htm - Informe de la NTA 2025, "Sistema de nueva generación (KSK2)"
https://www.nta.go.jp/about/introduction/torikumi/report/2025/03_5.htm - e-Tax, "Sobre el horario de mantenimiento por la renovación del sistema tributario nacional"
https://www.e-tax.nta.go.jp/topics/2026/topics_20260422.htm - e-Tax, "Lista de avisos"
https://www.e-tax.nta.go.jp/topics/ - e-Tax, "[Resuelto] Sobre la imposibilidad de usar e-Tax"
https://www.e-tax.nta.go.jp/topics/2026/topics_20260925_mentenansu.htm - NIST SP 800-34 Rev.1, Contingency Planning Guide for Federal Information Systems
https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final - Google Site Reliability Engineering, Handling Overload / Effective Troubleshooting
https://sre.google/sre-book/handling-overload/
https://sre.google/sre-book/effective-troubleshooting/ - Amazon Builders’ Library, Making retries safe with idempotent APIs
https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/
