El modelo operativo como código: reglas y excepciones ejecutables

Toda empresa funciona sobre procesos, reglas de decisión, excepciones y umbrales. En muchas compañías, una parte de ese modelo está repartida entre personas, correos y hábitos que no aparecen en la documentación. Se puede codificar, ejecutar con agentes y revisar con los datos de cada caso. El trabajo es específico de la empresa porque el contenido que se codifica también lo es.

Tu empresa ya funciona con reglas; solo que no están escritas

Tener procesos documentados no implica que la documentación describa lo que se ejecuta.

La documentación suele describir el proceso aprobado. La operación incorpora cambios acumulados: confirmar por teléfono el stock de cierto cliente, aprobar devoluciones por debajo de un umbral o tratar con un proveedor mediante una persona concreta. Si esas decisiones no aparecen en el manual, el manual no basta para automatizar el proceso.

La brecha entre lo documentado y lo ejecutado tiene un coste: cada nuevo empleado tarda meses en aprender lo no escrito, cada baja puede llevarse conocimiento y cada intento de automatizar descubre reglas ausentes. El mismo problema afecta a los pilotos probados solo con datos preparados, como cuento en por qué fracasan los pilotos de IA.

Qué significa codificarlo

Modelo operativo como código no significa dibujar diagramas de proceso más bonitos. Los diagramas describen. El código ejecuta, y esa diferencia lo cambia todo.

Codificar el modelo operativo es convertir los procesos, las reglas de decisión, las rutas de excepción y los límites de autoridad en definiciones que los agentes ejecutan directamente: qué pasos tiene el proceso, con qué criterios se decide en cada bifurcación, qué casos escalan a qué personas, qué puede hacer cada agente y hasta dónde. Con cada acción registrada, cada excepción trazada y cada regla en un solo sitio, versionada como se versiona el software.

La diferencia frente a un manual está en la ejecución. Un documento puede quedar desactualizado sin generar una señal. Si el proceso codificado deja de corresponderse con la operación, aparecen errores o escalados que obligan a revisar la regla. La distancia entre definición y práctica se convierte en un dato observable.

Los agentes también ayudan a completar el modelo. Si empiezan con permisos limitados y escalan los casos no cubiertos, cada escalado señala una regla ausente o una decisión que debe asignarse. La codificación puede avanzar junto a la operación en lugar de depender de un análisis previo de toda la empresa.

Por qué esto no se configura solo

Un producto horizontal parte de supuestos comunes a muchos clientes.

Ese enfoque funciona para contabilidad, nóminas o correo, donde adoptar un estándar no elimina una ventaja de la empresa. En un proceso propio, la plataforma puede aportar la infraestructura, pero alguien debe descubrir las reglas, convertirlas en definiciones ejecutables y revisarlas cuando cambia el negocio.

En los procesos ligados al margen, las excepciones recogen decisiones sobre clientes, riesgo y servicio. Un producto no las conoce antes de la implantación y solo puede ofrecer mecanismos para configurarlas. Cuando esa configuración exige descubrir y codificar el funcionamiento de la empresa, el trabajo sigue en fase custom. Desarrollo esa clasificación en el manifiesto de la fase custom.

Custom hoy no significa custom para siempre. Significa custom hasta que la evidencia diga qué partes se pueden estandarizar, y entonces productizar desde tu evidencia, no desde la abstracción prematura de otro.

Qué gana el que lo levanta primero

El resultado se puede observar en cuatro mecanismos.

Composición. Cada proceso codificado abarata el siguiente: la infraestructura de permisos y trazabilidad se reutiliza, las reglas comunes ya están escritas, el equipo ya sabe excavar. El primero cuesta lo que cuesta aprender. Del segundo en adelante se nota la pendiente. Quien empieza antes acumula antes.

Transferencia de conocimiento. Las reglas que dependían de personas concretas quedan legibles, versionadas y transferibles. Una baja conserva menos conocimiento fuera del sistema y la incorporación de nuevas personas parte de una definición común.

Mejora con evidencia. Un modelo que se ejecuta genera datos sobre sí mismo: qué reglas saltan, qué excepciones crecen, dónde se atasca el flujo. Discutir el proceso deja de ser una batalla de opiniones entre departamentos y pasa a ser una lectura de registros. Se mejora lo que se ve.

Migración. Cuando una parte del mercado se estandarice, la empresa que tiene sus reglas codificadas puede comparar el producto con requisitos observados y migrar solo los componentes cubiertos. Sin esa definición, no puede medir qué comportamiento pierde al cambiar.

Este modelo codificado es un requisito de una organización AI-first: los agentes no pueden asumir responsabilidades estables si el proceso que ejecutan no está definido.

Por dónde se empieza

Se empieza por un proceso con responsable, resultado verificable y excepciones frecuentes pero acotadas. Se codifica la versión que se ejecuta, se asignan permisos mínimos y se usan los escalados para encontrar reglas ausentes. Permisos, límites y registro forman parte del diseño inicial, como explico en gobernanza de agentes. Las condiciones previas están en preparar tu empresa para agentes.

Este es el trabajo específico que hacemos en Arkatai. El forward-deployed engineer incorpora las reglas y excepciones al sistema. Nuestro equipo mantiene la plataforma y el cliente conserva la autoridad sobre el proceso.

Preguntas que me hacen los comités

¿En qué se diferencia esto de documentar procesos, que ya lo hemos hecho?

La documentación describe. El modelo codificado se ejecuta. Cuando cambia la operación y la regla no, aparecen errores o escalados que permiten localizar la diferencia. El formato importa menos que la conexión con la ejecución.

Nuestros procesos no están ordenados. ¿No deberíamos arreglarlos antes?

Codificar un proceso permite localizar qué pasos y excepciones requieren una decisión. Se empieza por la versión que se ejecuta y se corrigen las reglas que no se pueden justificar. Los programas que intentan ordenar toda la empresa antes de operar suelen producir documentación que vuelve a quedar desactualizada.

¿Esto no nos ata a una tecnología concreta?

La plataforma sigue siendo de Arkatai, pero la arquitectura operativa específica es del cliente. Al terminar el contrato recibe su versión vigente y las exportaciones acordadas de datos, resultados y trazas. Puede llevar ese paquete a otro implementador o usarlo para construir software propio. La dependencia del runtime existe mientras prestamos el servicio. El conocimiento codificado de la operación no queda cautivo.

¿Quién mantiene ese código cuando cambie el negocio?

El dueño del proceso decide los cambios y el operador técnico los incorpora al sistema. En el modelo gestionado, esa segunda función corresponde al equipo de Arkatai y a sus FDE, no a un futuro departamento de IA del cliente. Si las reglas no se revisan, la definición dejará de representar la operación.