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 nuevo circuito sin caerse. Se sacan capturas, alguien felicita al equipo y la agenda empieza a llenarse con el proyecto siguiente. Si hubo capacitación y un manual, la entrega se considera completa.

Sin embargo, la vida de un sistema comienza justamente cuando termina el proyecto que lo produjo. Hasta ese momento fue usado por personas que conocían sus objetivos, que podían hablar con quienes lo construyeron y que 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 los repartos se acumulaban, 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 de manera distinta. Desde la infraestructura, todo funcionaba. Desde el trabajo, el puente empezaba a desarmarse.

Llamo higiene sociotécnica al 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 siendo válidas, 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, aumenta la latencia o cambia la distribución de los datos. Los equipos técnicos tienen instrumentos para observar gran parte de ese deterioro. La segunda es más difícil de detectar porque sucede 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 obliga a registrar una secuencia que ya no coincide con el trabajo, de modo que las personas completan el sistema después, como una tarea administrativa. 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 exige trabajo pero ya no devuelve ayuda. Al final aparece la frase que suele interpretarse como resistencia: “antes lo hacíamos más rápido”. A veces es una idealización del pasado. Otras veces es un diagnóstico correcto.

La higiene parte de 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 constituye por sí solo higiene sociotécnica. El soporte repara fallas o responde consultas. La higiene crea dentro de la organización la capacidad de advertir que el sistema y el trabajo se están separando.

Eso exige 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 o de la forma en que se atiende una excepción comercial. Puede custodiar la infraestructura y facilitar cambios, pero el significado pertenece al negocio y sus consecuencias, a quienes realizan el trabajo. Cada rutina necesita una persona identificable, una frecuencia razonable y un criterio que indique cuándo actuar.

No todas las organizaciones necesitan 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 ser más efectiva 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 está usando otra herramienta porque la oficial no resuelve su necesidad?

La respuesta a esas preguntas debe 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 condiciones que obligarían a revisarlas. Un documento enorme que nadie abre es menos útil 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 existe una necesidad de inteligencia artificial no llega mediante una propuesta formal. Llega cuando alguien descubre que un empleado está usando 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 debe clausurarse. Los dos pierden una parte del fenómeno. El shadow AI 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 sobre el costo de las brechas del mismo año, relacionó 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 conviene mirar el trabajo.

Quien pega un contrato en un modelo público para obtener un resumen probablemente no comenzó 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 disponible. Quien redacta respuestas con una cuenta personal tal vez está cubriendo una demanda que creció sin que aumentara el equipo. La conducta puede ser imprudente y necesitar un límite claro. A la vez, señala con notable precisión dónde existe una tarea costosa y una expectativa de ayuda.

Por eso el shadow AI debe entrar 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 trasladarse 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 IA, sino simplificar el proceso que obligaba a buscar el atajo.

Una prohibición sin alternativa hace 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í necesita saber qué condiciones deberá cumplir para avanzar. Los puntos de control entre exploración, piloto y operación permiten detener una solución antes de que el entusiasmo se convierta en dependencia.

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

El retiro suele olvidarse porque contradice la narrativa de crecimiento permanente. Sin embargo, 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 por inercia también es una forma de deuda.

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

También hace falta vigilar el comportamiento humano alrededor del modelo. Una tasa de aceptación demasiado alta puede ser tan preocupante como una demasiado baja: 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

Hay cuidados cuya importancia solo se vuelve visible cuando faltan. Los respaldos son el ejemplo clásico. Configurar una copia automática produce tranquilidad, pero la única prueba real es poder restaurarla. Un respaldo jamás probado es una esperanza, no una protección.

Lo mismo ocurre con el tiempo de recuperación y la pérdida aceptable de datos. RTO y RPO suelen presentarse como siglas de infraestructura, aunque en realidad 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. Debe acordarse 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 infraestructura sin tercerizar la obligación de administrar accesos, clasificar datos, probar recuperaciones y preparar una salida. Si el proveedor cambia condiciones o aumenta el precio, la portabilidad deja de ser una discusión arquitectónica y se transforma 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 convierte de inmediato en filas, ventas perdidas y personas improvisando. Diseñar contingencias no es sobredimensionar: es conocer cuánto cuesta quedar desconectado y decidir en consecuencia.

Después de un incidente, el postmortem debería ampliar la capacidad del sistema para aprender. Reconstruir qué ocurrió, qué barreras fallaron y qué señales estuvieron disponibles produce controles mejores. Buscar un culpable rápido produce silencio. La responsabilidad sigue existiendo, pero es más útil cuando se entiende la configuración que hizo posible el error.

Enseñar el criterio

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

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

La formación también debe alcanzar a las personas que llegarán 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 que se dicta una vez al año puede ser impecable y, aun así, no resolver su problema.

Marcar el cambio

Los procesos anteriores no desaparecen solo porque el nuevo sistema esté disponible. Durante un tiempo conviven en la cabeza de las personas. Allí 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.

Por eso sirven los rituales de transición. Una retrospectiva puede reconocer qué resolvía bien el viejo proceso y qué costo ya no conviene pagar. Ese cierre no romantiza el pasado; incorpora lo aprendido. La apertura, por su parte, necesita un espacio explícito para las primeras quejas. Una observación durante 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 acto simple de ponerle nombre al nuevo flujo. Lo central es reconocer que el cambio también modifica 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 ocurre cuando quien lo construyó deja de estar presente. Si cada decisión vuelve al consultor, si nadie se anima a actualizar una definición o si un incidente solo puede resolverse 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; probar que la organización puede ejecutar 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 mediante 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 significado, que las excepciones tengan un lugar, que las personas nuevas puedan aprender y que un problema llegue a la conversación antes de convertirse en 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 multidimensionales · El puente aplicado al sector público