⚖️💻 𝐂𝐚𝐦𝐛𝐢𝐚𝐫 𝐮𝐧 𝐬𝐢𝐬𝐭𝐞𝐦𝐚 𝐝𝐞𝐥 𝐄𝐬𝐭𝐚𝐝𝐨 𝐧𝐨 𝐞𝐬 𝐜𝐚𝐦𝐛𝐢𝐚𝐫 𝐞𝐥 𝐟𝐨𝐧𝐝𝐨 𝐝𝐞 𝐩𝐚𝐧𝐭𝐚𝐥𝐥𝐚

Han visto que siempre cuando alguien visita una represa, pregunta por qué no abren todas las compuertas de una sola vez para que el agua salga más rápido.

Desde afuera parece una decisión sencilla.

Hasta que uno entiende que detrás hay cálculos, normas, riesgos y consecuencias que no se ven a simple vista.

Con los sistemas del Estado ocurre algo parecido.

Muchas personas creen que modificar una funcionalidad es tan simple como pedirlo.

"Agreguen este botón."

"Cambien esta regla."

"Saquen este requisito."

"Automaticen este proceso."

Y a veces incluso se molestan cuando la respuesta no es inmediata.

Pero en el sector público las cosas suelen ser más complejas.

Porque un sistema no siempre refleja una decisión tecnológica.

Muchas veces refleja una ley.

Un reglamento.

Una normativa.

Un dictamen.

Un procedimiento administrativo.

Un requisito de control.

Una obligación legal.

Y eso cambia completamente la conversación.

Como viejo gruñón tecnológico, aprendí que uno de los errores más comunes es pensar que el sistema manda.

La mayoría de las veces el sistema obedece.

Obedece a reglas definidas fuera del área informática.

Obedece a marcos regulatorios.

Obedece a leyes que fueron aprobadas años antes de que alguien escribiera una sola línea de código.

Por eso cuando alguien pide un cambio, el profesional informático no solo tiene el derecho de cuestionar la solicitud.

Tiene la responsabilidad de hacerlo.

No para bloquear.

No para decir que no.

Sino para entender.

¿La modificación cumple la normativa?

¿Genera conflictos legales?

¿Afecta controles obligatorios?

¿Impacta procesos de otros organismos?

¿Modifica derechos de las personas?

¿Existe respaldo jurídico para implementarla?

Porque una mala decisión tecnológica puede generar un incidente.

Pero una mala decisión que contradice la ley puede generar problemas mucho mayores.

Y eso es algo que muchas veces no se ve desde fuera.

El rol del profesional de tecnología no consiste únicamente en programar lo que le piden.

También consiste en advertir riesgos.

Hacer preguntas incómodas.

Detectar inconsistencias.

Y levantar la mano cuando una solicitud puede tener consecuencias que otros no están considerando.

Las mejores organizaciones públicas no tienen informáticos que obedecen ciegamente.

Tienen profesionales capaces de dialogar con abogados, auditores, áreas de negocio y autoridades para asegurar que la tecnología siga sirviendo al propósito para el cual fue creada.

Porque cuestionar una orden no siempre es un acto de resistencia.

Muchas veces es un acto de responsabilidad.

Y créanme, después de suficientes años viendo proyectos públicos, descubrí que las preguntas difíciles antes de implementar un cambio suelen ser muchísimo más baratas que las explicaciones que vienen después. ⚖️💀

En el Estado, una línea de código rara vez es solo una línea de código.

Muchas veces es la materialización digital de una norma, un derecho o una obligación que afecta a miles de personas. 🇨🇱⚙️✨