Lo que enseña construir software para un municipio

En un producto de consumo una fecha es una meta: si se pasa, alguien se molesta. En un trámite administrativo una fecha es un hecho jurídico. Radicar no es guardar un registro con una marca de tiempo; es arrancar un reloj que escribió otro, con consecuencias para el ciudadano y para la entidad. Los días hábiles, los festivos y la hora exacta dejan de ser casos borde de una función de fechas y pasan a ser el centro del dominio.

Eso cambia cómo se despliega. No existe el lanzar y ya iremos ajustando cuando lo que está en juego es un expediente abierto: un trámite que empezó bajo unas reglas tiene que poder terminar bajo esas reglas. Las migraciones conservan la historia en vez de corregirla, y una corrección se registra como corrección, con su fecha y su autor. El sistema no puede quedar nunca en un estado donde sea imposible reconstruir qué decía ayer.

La consecuencia práctica es que la trazabilidad no es una función que se agrega después, en la pestaña de auditoría. Es una propiedad del modelo desde el primer día y condiciona todo lo demás: qué se puede borrar, qué se puede editar, qué solo se puede anular dejando rastro. Diseñar eso al final habría significado reescribir el sistema entero, y esa es exactamente la lección que un municipio te enseña temprano.

Tramo tiene 138 entidades de dominio repartidas en unos 40 módulos. Ese número no es la ambición de un arquitecto: es una transcripción. El dominio existía desde antes, escrito en normativa, en formatos, en resoluciones y en la manera en que la secretaría ya trabajaba. Modelarlo consistió en leer y preguntar mucho más que en inventar. Cuando el software se adelanta y simplifica un procedimiento que no entendió, no lo mejora: lo deja sin poder emitir el documento que debía emitir.

Por eso las entidades se llaman como las llama la norma, no como sonarían mejor en inglés. Suena a detalle menor y no lo es: cuando el modelo usa el vocabulario de la oficina, las revisiones con los funcionarios dejan de ser un ejercicio de traducción y pasan a ser una revisión de verdad. Ellos señalan el error donde está, y yo puedo discutir el procedimiento en vez de discutir mis nombres.

La base es deliberadamente aburrida: NestJS sobre Fastify, TypeORM y un frontend en Next.js. Aburrida porque el valor está en el dominio y porque este software tiene que seguir funcionando dentro de muchos años, con gente que no estuvo cuando se escribió. En una institución, la parte interesante del sistema nunca debería ser la infraestructura, sino el procedimiento que sostiene.

Quien de verdad vive dentro de Tramo es un funcionario que abre las mismas pantallas todos los días del año. Eso invierte casi todas las prioridades habituales de diseño. Lo que importa no es la primera impresión, sino el camino frecuente hecho corto, la recuperación de un error a medio expediente y que la información que necesita consultar de reojo esté siempre en el mismo sitio. Nadie está descubriendo esta herramienta: la están usando.

Al mismo tiempo hay menos margen para explorar que en cualquier producto de consumo. Un botón no es un experimento cuando lo que firma tiene efectos jurídicos, así que la interfaz tiene que decir con claridad qué está a punto de pasar, quién queda como autor y qué se puede deshacer. La ansiedad del usuario aquí no se combate con animaciones, sino haciendo que el sistema sea previsible y que la responsabilidad quede siempre visible.

Y del otro lado está la consulta pública ciudadana: el mismo expediente, mirado desde afuera por alguien que no trabaja allí. Esa ventana es la que convierte todo lo anterior en algo comprobable. Un dato mal cargado deja de ser una inconsistencia interna y se vuelve una respuesta equivocada a un vecino que preguntó por su barrio. Saber que existe esa mirada disciplina el diseño mejor que cualquier documento de requisitos.

Construyo agentes todos los días, y aquí voy más despacio a propósito. Dentro del expediente hay un asistente que usa RAG y una base de datos vectorial para ayudar a encontrar lo que ya está escrito en el propio expediente. Está en fase experimental, en desarrollo, y así se nombra siempre: no es una función entregada al ciudadano ni la voy a presentar como si lo fuera. En un municipio esa distinción no es prudencia comercial, es honestidad básica.

Las razones son concretas. Una decisión administrativa tiene que ser atribuible a una persona que responde por ella, y ningún modelo puede ocupar ese lugar. Una respuesta generada que suena correcta y está mal cuesta muchísimo más que una respuesta que no llega, porque nadie la va a verificar dos veces si viene bien redactada. Y una recuperación sobre documentos normativos hay que evaluarla antes de que alguien la use para decidir, no después.

Por eso el encuadre correcto es ayudar a encontrar, nunca decidir. Buscar dentro del expediente, mostrar de dónde salió cada cosa y dejar que el funcionario compruebe. Ese techo es una decisión de diseño tomada a conciencia, no una limitación técnica que ya se resolverá; ampliarlo exigiría una evaluación seria de la calidad de las respuestas y una conversación con la entidad, en ese orden.

La lección se me quedó y la llevo a los demás proyectos: la ambición de un agente tiene que ir a la medida del coste de equivocarse. En un pedido por WhatsApp, equivocarse es un plato mal tomado y una persona arreglándolo en dos minutos. En un trámite, equivocarse puede afectar el derecho de alguien. La disciplina de ingeniería es la misma en los dos casos. La velocidad a la que se suelta, no.