Higiene sociotécnica

El día del lanzamiento tiene una capacidad engañosa para parecer un final. Después de semanas o meses de trabajo, el sistema responde, los accesos están creados y una primera operación real atraviesa el circuito nuevo sin caerse. Se sacan capturas, alguien felicita al equipo y la agenda empieza a llenarse con el proyecto siguiente. Si hubo capacitación y manual, la entrega se da por completa.

La vida de un sistema, sin embargo, empieza cuando termina el proyecto que lo produjo. Hasta ese momento lo usaron personas que conocían sus objetivos, podían hablar con quienes lo construyeron y prestaban una atención extraordinaria a cada resultado. Después del lanzamiento entra en la jornada común. Lo usa alguien apurado, llega un dato que no figuraba en los ejemplos, cambia un proveedor, se incorpora una persona nueva y el proceso que parecía estable se acomoda a una urgencia. Ahí se descubre si se construyó un artefacto o una capacidad.

Distribuidora Norte había logrado poner en producción sus alertas de clientes en riesgo. Los vendedores consultaban la herramienta y las sucursales, después de varias discusiones, compartían una definición de “última compra”. Seis meses más tarde el sistema seguía encendido y sus indicadores de disponibilidad eran impecables. Aun así, algo se estaba rompiendo. Los viernes, cuando se acumulaban los repartos, reaparecía una planilla paralela. Algunas alertas se cerraban sin comentario. Dos vendedores nuevos habían aprendido el procedimiento mirando a sus compañeros, y cada uno lo había aprendido distinto. Desde la infraestructura, todo funcionaba. Desde el trabajo, el puente empezaba a desarmarse.

Lo que este libro llama higiene sociotécnica es el conjunto de cuidados que evita ese deterioro. La palabra higiene es deliberadamente cotidiana. No describe una auditoría excepcional ni una intervención de rescate, sino hábitos modestos y repetidos: revisar si las definiciones siguen valiendo, escuchar los rodeos que inventó el equipo, probar un respaldo, conversar sobre un error del modelo, actualizar quién puede autorizar una excepción. Ninguna de esas acciones tiene el brillo de un lanzamiento. Juntas determinan cuánto dura su valor.

El desgaste que no aparece en el tablero técnico

Los sistemas se degradan de dos maneras. La primera es conocida: envejece una dependencia, falta capacidad, vence un certificado, sube la latencia o cambia la distribución de los datos. Los equipos técnicos tienen instrumentos para observar buena parte de ese deterioro. La segunda cuesta más detectarla, porque ocurre en la relación entre la herramienta y la organización.

Una categoría cambia de significado en la práctica, pero no en el glosario. Un permiso concedido como excepción se vuelve rutina. El responsable de un indicador cambia de puesto y nadie hereda la obligación de revisarlo. Una pantalla exige registrar una secuencia que ya no coincide con el trabajo, y entonces las personas completan el sistema después, como un trámite administrativo. Cada desajuste es pequeño. Su acumulación produce deuda sociotécnica: el costo futuro de haber dejado sin cuidado el vínculo entre la parte humana y la parte técnica.

La deuda se reconoce por sus intereses. Hay que conciliar más fuentes, responder más consultas y explicar una y otra vez por qué el tablero contradice la experiencia. El equipo empieza a confiar en nombres propios en lugar de procesos: “preguntale a Laura, ella sabe cuál es el número bueno”. Los responsables sienten que el sistema les pide trabajo y ya no les devuelve ayuda. Al final aparece la frase que suele leerse como resistencia: “antes lo hacíamos más rápido”. A veces es una idealización del pasado. Otras, un diagnóstico correcto.

La higiene empieza por tomar esa frase en serio. No promete volver atrás, pero tampoco la descarta. Pregunta qué tarea creció, qué excepción se perdió y qué parte del beneficio dejó de ser visible para quien sostiene la carga cotidiana.

Cuidar no es contratar mantenimiento eterno

Un contrato de soporte puede ser necesario, pero no alcanza por sí solo. El soporte repara fallas y responde consultas. La higiene crea, dentro de la organización, la capacidad de advertir que el sistema y el trabajo se están separando.

Para eso hacen falta responsables concretos. “El área de sistemas” no puede ser dueña de la definición de cliente activo, del criterio para rechazar una recomendación ni de la forma de atender una excepción comercial. Puede custodiar la infraestructura y facilitar cambios, pero el significado pertenece al negocio, y sus consecuencias, a quienes hacen el trabajo. Cada rutina necesita una persona identificable, una frecuencia razonable y un criterio que indique cuándo actuar.

No toda organización necesita un comité formal. En una pyme, una conversación mensual de cuarenta minutos entre operaciones, administración y la persona que cuida los datos puede rendir más que una estructura de gobierno copiada de una multinacional. Lo importante es que la conversación exista, mire evidencia y termine con decisiones. ¿Qué rodeos aparecieron? ¿Qué dato generó discusiones? ¿Qué cambió en el proceso? ¿Hay una alerta que todos ignoran? ¿Alguien usa otra herramienta porque la oficial no resuelve lo que necesita?

Las respuestas deben dejar un rastro breve. La documentación viva no aspira a registrarlo todo. Conserva lo que una persona nueva necesitaría para entender el razonamiento del sistema: definiciones, responsables, límites conocidos, decisiones de diseño y las condiciones que obligarían a revisarlas. Un documento enorme que nadie abre sirve menos que una página precisa que cambia junto con el proceso.

Lo que el shadow AI está diciendo

En muchas organizaciones, la primera señal de que hay una necesidad de inteligencia artificial no llega como propuesta formal. Llega cuando alguien descubre que un empleado usa por su cuenta un asistente público para resumir documentos, escribir respuestas o analizar una planilla. Puede haber copiado información interna. Tal vez sabía que la política lo prohibía y prefirió no contarlo.

La reacción inmediata suele oscilar entre dos extremos. Uno celebra la iniciativa: por fin la gente innova sin esperar permisos. El otro ve una falta que hay que clausurar. Los dos pierden una parte del fenómeno. El shadow AI, el uso de herramientas de IA por fuera de los canales que la organización aprobó, puede exponer datos y crear resultados imposibles de auditar. También revela una demanda que los canales oficiales no estaban atendiendo.

El estudio global de la Universidad de Melbourne y KPMG de 2025 encontró que casi la mitad de las personas encuestadas reconocía usos contrarios a las políticas de su organización. IBM, en su informe del mismo año sobre el costo de las brechas de seguridad, asoció una presencia alta de shadow AI con costos adicionales de cientos de miles de dólares. Las cifras dimensionan el riesgo, pero no explican por qué ocurre. Para eso hay que mirar el trabajo.

Quien pega un contrato en un modelo público para obtener un resumen probablemente no empezó el día con la intención de violar una política. Tenía que leer cincuenta páginas antes de una reunión y encontró una herramienta a mano. Quien redacta respuestas con una cuenta personal tal vez está cubriendo una demanda que creció sin que creciera el equipo. La conducta puede ser imprudente y necesitar un límite claro. A la vez, señala con notable precisión dónde hay una tarea costosa y una expectativa de ayuda.

Por eso el shadow AI entra al diagnóstico como síntoma. Primero se reconstruyen los usos reales, sin organizar una cacería. Luego se clasifican los datos y el impacto de cada caso: no es lo mismo corregir un texto público que resumir una historia clínica o recomendar una decisión de crédito. Después se ofrecen caminos gobernados. Algunos usos podrán pasar a una herramienta con contrato y controles adecuados; otros requerirán anonimización, revisión humana o prohibición. En ciertos casos se descubrirá que la mejor respuesta no es la IA, sino simplificar el proceso que empujaba a buscar el atajo.

Una prohibición sin alternativa solo consigue que la práctica se esconda mejor. Una apertura sin reglas normaliza el riesgo. La higiene trabaja en el espacio menos cómodo entre ambas: reconoce la necesidad, hace visible el costo y construye una opción que la gente pueda usar sin mentir sobre lo que hace.

Del piloto al retiro

La gobernanza acompaña todo el ciclo de vida. Una idea todavía exploratoria no necesita los mismos controles que un sistema en producción, pero sí saber qué condiciones tendrá que cumplir para avanzar. Los puntos de control entre exploración, piloto y operación permiten frenar una solución antes de que el entusiasmo se convierta en dependencia.

En el piloto se pregunta si el caso de uso está bien definido, qué datos toca y cómo se va a medir el resultado. Antes de la puesta en producción se suman responsables, monitoreo, mecanismos de apelación y un plan para incidentes. Durante la operación se vigila la deriva. Y cuando el sistema deja de justificarse, se lo retira de manera deliberada: se conservan los registros necesarios, se revocan los accesos y se acompaña a las personas hacia el flujo que lo reemplaza.

El retiro suele olvidarse porque contradice el relato del crecimiento permanente. Pero un sistema que nadie se anima a apagar sigue consumiendo presupuesto, atención y superficie de riesgo. La higiene incluye revisar si la herramienta todavía resuelve el problema que le dio origen. Mantener algo por inercia también es una forma de deuda.

Cuando hay modelos, el monitoreo no puede reducirse a la disponibilidad. Un clasificador de reclamos puede seguir respondiendo y, aun así, empezar a tratar distinto a ciertos grupos porque cambiaron los datos o el uso. En sistemas de alto impacto, la evaluación algorítmica tiene que ser una práctica periódica: si el contexto cambia, el informe del lanzamiento deja de describir el riesgo actual.

También hay que vigilar el comportamiento humano alrededor del modelo. Una tasa de aceptación demasiado alta puede preocupar tanto como una demasiado baja, porque quizá las personas dejaron de revisar. Un volumen creciente de correcciones manuales puede indicar deriva, pero también que apareció un caso que el diseño nunca contempló. Los números abren la investigación; no la cierran.

La parte aburrida que sostiene el negocio

Algunos cuidados solo muestran su importancia cuando faltan. Los respaldos son el ejemplo clásico. Configurar una copia automática da tranquilidad, pero la única prueba real es poder restaurarla. Un respaldo que nunca se probó es una esperanza, no una protección.

Lo mismo pasa con dos preguntas que en infraestructura se abrevian RTO y RPO: cuánto tiempo puede estar caído un servicio y cuántos datos se pueden perder sin daño grave. Suelen presentarse como siglas técnicas, aunque expresan decisiones de negocio. ¿Cuántas horas puede estar sin operar un punto de venta? ¿Cuántos pedidos puede reconstruir el equipo si falla la base? La respuesta no debería inventarla quien administra el servidor. Hay que acordarla con las personas que conocen el costo de una interrupción.

La nube tampoco elimina estas responsabilidades: las reparte entre proveedor y cliente. Una organización puede tercerizar la infraestructura sin tercerizar la obligación de administrar accesos, clasificar datos, probar recuperaciones y preparar una salida. Si el proveedor cambia las condiciones o sube el precio, la portabilidad deja de ser una discusión de arquitectura y se convierte en capacidad de negociación.

La conectividad merece la misma atención. Desde una oficina con internet estable es fácil tratar la red como un detalle. En un punto de venta, un depósito o un centro de atención, una caída se traduce de inmediato en filas, ventas perdidas y personas improvisando. Diseñar contingencias es conocer cuánto cuesta quedar desconectado y decidir en consecuencia, no sobredimensionar.

Después de un incidente vale la lógica que la práctica reflexiva aplica a los proyectos: reconstruir qué barreras cedieron y qué señales estaban disponibles produce controles mejores; buscar un culpable rápido produce silencio.

Enseñar el criterio

La transferencia habitual muestra pantallas y procedimientos. Eso alcanza mientras todo ocurre como en la demostración. El aprendizaje real se prueba frente a una excepción. Quien recibe el sistema necesita saber por qué se eligió una regla, dónde deja de valer y a quién consultar cuando el contexto cambia.

Esa transferencia de criterio puede tomar varias formas: trabajar juntos sobre casos reales, documentar las decisiones difíciles, rotar responsabilidades y dejar que el equipo interno conduzca una revisión con acompañamiento. La meta es que pueda razonar sin quien diseñó el sistema, no que repita sus palabras.

La formación también tiene que llegar a quienes se incorporen después. Si todo el conocimiento vive en quienes participaron del proyecto, cada incorporación reinicia el riesgo. Una organización con alta rotación necesita recorridos breves y frecuentes, integrados al trabajo. Un curso intensivo dictado una vez al año puede ser impecable y, aun así, no resolver su problema.

Marcar el cambio

Los procesos anteriores no desaparecen porque el sistema nuevo esté disponible. Durante un tiempo conviven en la cabeza de las personas, y en ellos hay destrezas, orgullo y también maneras de protegerse. Si el lanzamiento ridiculiza todo lo anterior, el mensaje para quienes sostuvieron el trabajo es que su experiencia perdió valor de un día para el otro.

Para eso sirven los rituales de transición. Una retrospectiva puede reconocer qué resolvía bien el proceso viejo y qué costo ya no vale la pena pagar. Ese cierre no idealiza el pasado; incorpora lo aprendido. La apertura, por su parte, necesita un espacio explícito para las primeras quejas. Una observación hecha en la primera semana suele ser un dato de diseño. Ignorada durante meses, se convierte en resentimiento y en un rodeo difícil de desarmar.

Los rituales no requieren solemnidad. Pueden ser una reunión breve, una demostración conducida por los propios usuarios o el gesto simple de ponerle nombre al flujo nuevo. Lo central es reconocer que el cambio también toca identidades: quién sabe, quién ayuda, quién autoriza, quién queda expuesto. Esas posiciones se negocian en la práctica, no en el organigrama.

Saber retirarse

La calidad del puente se ve en lo que pasa cuando quien lo construyó deja de estar. Si cada decisión vuelve al consultor, si nadie se anima a actualizar una definición o si un incidente solo se resuelve llamando a la persona externa que conoce la historia, el sistema funciona a costa de una dependencia.

Retirarse bien es una etapa del diseño. Implica dejar responsables, rutinas y memoria; comprobar que la organización puede hacer una revisión sin ayuda; acordar cuándo vale la pena pedir una mirada externa y cuándo no. El rol de consejero puede continuar con auditorías espaciadas, pero no debería reemplazar la capacidad interna.

La higiene sociotécnica persigue un resultado poco visible: que el sistema deje de necesitar heroísmo. Que los datos conserven su significado, que las excepciones tengan un lugar, que las personas nuevas puedan aprender y que un problema llegue a la conversación antes de volverse crisis. Nada de eso produce una foto memorable. Produce algo mejor: una transformación que todavía tiene sentido cuando ya nadie recuerda el día del lanzamiento.

Ver también: Conceptos propios · Psicología de la adopción · Métricas de valor · El puente aplicado al sector público