Durante muchos años el software se ha contado casi exclusivamente a través de sus características. Más funciones, más integraciones, más velocidad, más automatización. Hoy, naturalmente, más inteligencia artificial.
Cada nueva plataforma promete simplificar, optimizar, transformar. Sin embargo, observando el trabajo real — el de las personas, los operadores, las pequeñas empresas, las actividades que existen fuera de las presentaciones comerciales — emerge a menudo una sensación distinta: a pesar de toda esta tecnología, muchas actividades parecen hoy más frágiles, más dependientes, más confusas que antes.
No es una impresión casual.
La correcta valoración del "software"
En los últimos años hemos aprendido a valorar el software casi exclusivamente en términos de funcionalidades, olvidando una pregunta mucho más importante: ¿quién asume la responsabilidad de las consecuencias operativas de lo que se construye?
Es una pregunta menos espectacular que las demos de IA o los dashboards animados. Pero es la pregunta que determina si un sistema ayudará de verdad a las personas o añadirá una nueva capa de complejidad invisible.
Esta diferencia surge sobre todo en los contextos reales, donde los procesos no son lineales y donde el trabajo no se comporta como en los diagramas.
Muchas plataformas se diseñan lejos del lugar donde se van a usar. Quien construye el sistema a menudo no vive el territorio, no sigue a los operadores, no ve las excepciones cotidianas y no sufre las consecuencias de los errores. Poco a poco se crea una fractura: el software empieza a representar una realidad teórica en lugar de la real.
Los procesos se convierten en modelos abstractos. Las personas se convierten en usuarios. La presencia humana es sustituida por flujos y procedimientos estandarizados.
Esto funciona mientras todo parece ir bien. Luego llega el trabajo de verdad.
El software y los problemas reales
El fontanero que recibe tres urgencias al mismo tiempo en puntos distintos del territorio a través de una plataforma de seguros prácticamente imposible de integrar con otros sistemas. Y de hecho casi nadie la integra de verdad. La realidad operativa sigue viviendo en otro sitio: en las agendas de papel, en los mensajes de WhatsApp, entre Google Maps, llamadas telefónicas y memoria personal.
O el alojamiento turístico que descubre un problema eléctrico a las 22:30, con un huésped recién llegado. O el property manager que se mueve continuamente entre normativas, mantenimiento, relaciones humanas y plataformas distintas que no se comunican entre sí.
Ahí es donde se hace evidente la diferencia entre un sistema construido para parecer eficiente y un sistema construido asumiendo responsabilidades operativas.
La tecnología contemporánea ha desarrollado una especie de obsesión por las características. Cada producto se cuenta a través de palabras como automatización, AI integration, predictive intelligence, smart workflows. Mucho más raramente se habla de las dependencias creadas.
La vida de un software
¿Quién mantendrá ese sistema dentro de un año? ¿Qué pasará cuando un servicio externo cambie de API? ¿Los operadores lograrán entender de verdad qué está pasando o trabajarán dentro de una caja opaca? ¿Existe la posibilidad de intervenir manualmente cuando algo falla? Estas no son preguntas técnicas. Son preguntas de responsabilidad. Y sin embargo casi siempre ralentizan el relato comercial de la tecnología, que prefiere centrarse en las posibilidades en lugar de en las consecuencias.
Uno de los aspectos más interesantes de la automatización es que a menudo no elimina el trabajo. Lo desplaza.
El software que no ayuda
Muchos sistemas digitales reducen el trabajo visible de la empresa que vende el software, pero aumentan el trabajo invisible del operador final. La plataforma "simplifica", pero mientras tanto exige actualizaciones continuas, genera notificaciones constantes, fragmenta la información, obliga a las personas a hacer de puente entre sistemas distintos y fuerza a los operadores a adaptarse continuamente a la lógica de la plataforma.
El trabajo real no desaparece. Se redistribuye. Muy a menudo hacia quien tiene menos tiempo, menos apoyo y menos poder de decisión.
En el turismo, en el mantenimiento, en el sector inmobiliario y en la pequeña empresa este fenómeno ya es evidente. Muchos profesionales pasan más tiempo coordinando software que haciendo su propio trabajo.
Existe además un problema todavía más profundo: la pérdida del contexto.
El software y su contexto
Un territorio no es un dataset uniforme. Un operador no es un nodo abstracto. Un mantenimiento urgente no es simplemente un ticket que asignar.
Cada actividad real contiene relaciones, experiencia, excepciones, conocimiento local, confianza, historia y percepción. Son elementos difíciles de transformar en workflows estandarizados y precisamente por eso los sistemas centralizados los ignoran a menudo.
La tecnología contemporánea tiende a valorar lo que es fácilmente medible, dejando poco a poco en segundo plano todo lo que es difícil de modelar. Y sin embargo, muy a menudo, es precisamente lo que no se puede modelar fácilmente lo que determina si un servicio funciona de verdad.
En los últimos años hemos empezado a hablar mucho de AI ethics, pero mucho menos de transparencia operativa. Sin embargo el problema, en la mayoría de los casos, no es que un sistema sea "inteligente". El problema es que se vuelve opaco.
Cuando las personas ya no entienden por qué pasa algo, dónde están los datos, quién controla realmente el proceso o qué dependencias existen, el software deja poco a poco de ser una herramienta y se convierte en un entorno que hay que sufrir. Esto es especialmente crítico en las organizaciones pequeñas, que raramente tienen el tiempo o las competencias para entender sistemas cada vez más complejos. Por eso la transparencia no es una característica secundaria. Es infraestructura.
El software lento
Un buen sistema debería permitir a las personas entender qué está pasando, verificar los procesos, intervenir manualmente y mantener autonomía operativa incluso cuando el software evoluciona.
Quizá uno de los problemas contemporáneos es que hemos empezado a considerar la lentitud como un defecto absoluto. Y sin embargo muchos sistemas fiables son lentos de forma intencional. Lentos en el sentido de que privilegian la comprensión frente a la velocidad, la continuidad frente a la novedad, la claridad frente a la complejidad y la responsabilidad frente a la escala indiscriminada. Esto no significa rechazar la tecnología. Significa recordar que el valor de un sistema no depende solo de lo que consigue hacer, sino también de lo que hace comprensible, de lo que preserva y del tipo de dependencia que crea.
El software que ayuda
Las características cuentan, naturalmente. Pero llegan después. Antes debería haber otra pregunta, mucho más simple y mucho más difícil al mismo tiempo: ¿este sistema ayuda de verdad a las personas a mantener control, comprensión y responsabilidad sobre su propio trabajo? Si la respuesta no está clara, probablemente todavía no sea el momento de automatizar.
Durante muchos años la tecnología ha buscado sobre todo aumentar las posibilidades. Quizá en los próximos años sea más importante entender qué responsabilidades estamos dispuestos a asumir cuando construimos sistemas destinados a entrar en la vida real de las personas.