Serie: El código invisible de la empresa | 3 de 3
Las reglas internas de una empresa suelen revisarse una por una. Se modifica una política, cambia un límite de autorización, se ajusta un procedimiento o se incorpora una nueva condición en un sistema. Lo menos frecuente es detenerse a revisar qué ocurre cuando todas esas decisiones empiezan a funcionar juntas. Y, sin embargo, es ese conjunto el que termina definiendo buena parte de la forma real en que opera la organización.
En los dos artículos anteriores llamé a ese conjunto el código invisible de la empresa. Primero vimos que esas instrucciones pueden acumularse hasta dejar de responder a la organización que existe hoy. Después revisamos algo distinto: una decisión puede ser correcta y perder parte de su sentido cuando se convierte en reglas, procedimientos o instrucciones que otras personas tendrán que interpretar y aplicar.
Si esas reglas terminan funcionando juntas, tiene poco sentido administrarlas únicamente como documentos independientes. El efecto que producen depende también de la relación que guardan entre sí.
A ese conjunto propongo llamarlo arquitectura normativa organizacional. Ahí conviven las normas con las que una empresa distribuye facultades, fija límites, establece controles, admite excepciones y convierte muchas de sus decisiones en una forma concreta de trabajar. Algunas nacen de una obligación legal o contractual; otras responden a necesidades comerciales, financieras, operativas o de control. Su origen puede ser distinto y, sin embargo, terminan encontrándose dentro de la misma organización.
Hablar de arquitectura permite mirar las relaciones entre esas normas, y no solamente cada una por separado. Un límite financiero puede afectar una decisión comercial; una obligación contractual puede requerir un cambio operativo; una facultad puede resultar inútil si el proceso exige una autorización adicional en otro punto. Cada pieza puede parecer razonable por separado y producir, en conjunto, una forma de trabajar que nadie habría diseñado de esa manera.
Sostener esa arquitectura también consume recursos. Una regla puede exigir información, tiempo de revisión, supervisión o participación de varias personas. Ese costo puede estar plenamente justificado cuando protege a la empresa de un riesgo importante. La dificultad está en que pocas organizaciones vuelven a medirlo cuando cambian las circunstancias que dieron origen a la regla.
Hay normas que conservan perfectamente su razón de ser y otras cuya explicación se vuelve borrosa con los años. Se conoce el procedimiento, pero ya no siempre se recuerda qué problema buscaba resolver. Recuperar esa relación entre la regla y su propósito permite revisar algo más que su vigencia formal: permite saber si todavía vale la pena mantenerla como está.
La forma en que se escribe tampoco es un detalle menor. En el artículo anterior distinguíamos entre diseñar correctamente una regla y expresarla con claridad. Esa diferencia cobra mayor peso cuando la instrucción debe pasar después a otros documentos, procesos o sistemas. Una ambigüedad pequeña puede producir interpretaciones distintas y terminar alterando la operación.
Parte de esas normas termina traducida en permisos, parámetros, condiciones o flujos dentro de los sistemas. Conviene distinguir ambas cosas: la norma expresa una decisión organizacional; la configuración tecnológica es una de las formas en que esa decisión puede llevarse a la práctica. Entre una y otra puede aparecer nuevamente un problema de traducción.
Con inteligencia artificial esta relación se vuelve especialmente importante. Una empresa puede establecer quién debe supervisar una decisión, qué información puede utilizarse o hasta dónde puede actuar una herramienta. Después esas condiciones tienen que reflejarse en procesos y configuraciones que realmente produzcan ese resultado. La política aprobada y el comportamiento del sistema deberían responder a la misma decisión.
Para la gobernanza de IA, conservar esa correspondencia es especialmente importante. Buena parte de la conversación actual se concentra, con razón, en riesgos, controles, responsabilidades y supervisión. Pero esas decisiones necesitan reglas capaces de conservar su sentido cuando pasan del documento a la operación y de la operación a la tecnología. Una empresa puede tener una política adecuada y, al mismo tiempo, operar con un sistema configurado bajo criterios distintos.
Esa correspondencia tampoco permanece estable por sí sola. Los sistemas cambian, incorporan nuevas capacidades y modifican la forma de trabajar con una rapidez que muchas estructuras internas no siguen. Una herramienta autorizada para apoyar una tarea puede, meses después, hacer mucho más. Revisar la gobernanza de IA exige también comprobar si las normas que la sostienen siguen correspondiendo con lo que la tecnología puede hacer y con lo que la empresa quiere permitir.
Administrar esta arquitectura no debería convertirse en otra fuente de burocracia. Diseñar mejor puede significar eliminar una autorización, simplificar una regla, corregir una contradicción o retirar un control que dejó de aportar valor. En algunos casos hará falta una nueva disposición; en otros, reconocer que una anterior ya cumplió su función.
La calidad de esa arquitectura puede tener bastante que ver con la capacidad de una empresa para ejecutar sus decisiones. La estrategia necesita personas, recursos y tecnología, pero entre ellos circulan normas que pueden facilitar su coordinación o hacerla innecesariamente difícil. Ese espacio intermedio suele recibir menos atención que las piezas que conecta.
El código invisible seguirá existiendo. Lo relevante es decidir si continuará formándose casi por acumulación o si la empresa empezará a observarlo como una parte de su propia estructura, susceptible de diseño, revisión y gobierno. Con la inteligencia artificial ocupando cada vez más espacio en la operación, entender bien esa arquitectura deja de ser sólo una cuestión de orden interno. Empieza a ser también una condición para gobernar correctamente la relación entre personas, decisiones y tecnología.
