Inteligencia operacional

01 — Representar el objetivo y el criterio de finalización

Una operación necesita una definición clara de aquello que intenta conseguir.

Representamos:

• el objetivo;
• las entidades implicadas;
• el estado inicial;
• el resultado esperado;
• los estados intermedios;
• las restricciones;
• los permisos;
• los plazos;
• los riesgos;
• la señal de finalización.

Esta representación permite distinguir entre completar una tarea técnica y producir el efecto que importa a la organización.

02 — Reunir el contexto operativo

La información puede proceder de ERPs, CRMs, gestores documentales, bases de datos, APIs, mensajes, eventos, reglas y personas.

El sistema construye una vista suficiente del caso:

• qué se sabe;
• qué fuente posee cada dato;
• qué está vigente;
• qué información falta;
• qué decisión ya se tomó;
• qué autorización existe;
• qué permanece pendiente;
• qué cambió desde la última transición.

La inteligencia informacional aporta significado, evidencia y relaciones. La inteligencia operacional utiliza ese contexto para decidir qué recorrido puede continuar.

03 — Aplicar lógica y políticas

La lógica empresarial puede incluir:

• reglas de validación;
• cálculos;
• estados permitidos;
• políticas de autorización;
• segregación de funciones;
• umbrales;
• calendarios;
• condiciones contractuales;
• prioridades;
• excepciones;
• límites de riesgo;
• criterios de escalado.

Parte de esa lógica está formalizada. Otra debe reconstruirse a partir de código, configuraciones, documentación, trazas y conocimiento experto.

DocuLogic ayuda a hacerla examinable y a separar comportamiento observado, inferencia, validación y decisión organizativa.

La lógica que exige reproducción y control permanece en componentes deterministas. Los modelos intervienen allí donde existe interpretación, predicción, clasificación o elección contextual.

04 — Diseñar el reparto de trabajo

Cada parte del sistema debe ocupar una responsabilidad comprensible.

Reglas y cálculos

Aplican condiciones y transformaciones explícitas.

Machine learning

Aporta señales predictivas, rankings, anomalías, forecasts o estimaciones de probabilidad.

Optimización

Selecciona asignaciones, secuencias, prioridades o compromisos dentro de objetivos y restricciones.

Modelos lingüísticos

Interpretan solicitudes, comparan información, explican, resumen y componen lenguaje.

Agentes

Eligen entre herramientas o recorridos permitidos cuando la secuencia depende del contexto.

Workflows duraderos

Conservan estados, dependencias, eventos, esperas, reintentos y recuperación.

Personas

Aportan conocimiento, criterio, negociación, autoridad, responsabilidad y capacidad para cambiar la política.

Máquinas

Perciben y actúan en entornos físicos bajo límites de seguridad y control.

El diseño distribuye estas funciones y la orquestación mantiene unido el resultado.

05 — Orquestar agentes, software y personas

La orquestación decide:

• qué participante recibe el caso;
• qué contexto necesita;
• qué herramientas puede utilizar;
• qué salida debe producir;
• qué estado deja;
• qué permisos aplica;
• cuándo necesita ayuda;
• qué ocurre cuando falla;
• quién conserva la responsabilidad siguiente.

Un sistema multiagente aporta valor cuando existe especialización real, contextos separados, trabajo paralelo o revisión independiente.

La coordinación también añade coste, latencia y posibles fallos. Cada agente debe justificar su presencia mediante una función, unos contratos y un criterio de parada definidos.

06 — Mantener procesos duraderos

El trabajo puede durar segundos, días o meses. El tiempo forma parte del estado.

El sistema conserva:

• eventos esperados;
• plazos;
• autorizaciones pendientes;
• información solicitada;
• tareas dependientes;
• responsables;
• reintentos;
• acciones ya ejecutadas;
• versiones que cambiaron;
• preguntas abiertas;
• compromisos adquiridos;
• criterio para reanudar.

Un workflow duradero permite suspender el trabajo, recibir un evento y continuar desde un checkpoint sin reconstruir la historia ni duplicar acciones completadas.

07 — Diseñar la intervención humana

La participación humana cumple funciones diferentes y cada una necesita una interfaz propia.

Completar contexto

Una persona aporta información que el sistema no puede establecer.

Validar una inferencia

Una especialista confirma, corrige o acota una interpretación.

Decidir un compromiso

La situación enfrenta objetivos, costes o riesgos que requieren criterio.

Autorizar

La acción necesita una autoridad formal.

Resolver una excepción

El caso no coincide con los recorridos existentes.

Corregir o detener

La persona modifica el contexto, rechaza la propuesta, detiene el proceso o cambia su dirección.

Mejorar la política

Las excepciones y decisiones repetidas permiten revisar reglas, umbrales y responsabilidades.

Una intervención útil presenta:

• el objetivo;
• el estado;
• la razón de la derivación;
• la evidencia relevante;
• la acción propuesta;
• las alternativas;
• las consecuencias;
• la autoridad solicitada;
• el siguiente paso.

Así, el human in the loop se convierte en una función de conocimiento y decisión. La intervención humana se diseña con una función, un contexto y una autoridad definidos.

08 — Ejecutar mediante herramientas bajo contrato

Las acciones se exponen mediante herramientas con una interfaz explícita.

Cada herramienta declara:

• entradas;
• salidas;
• identidad;
• permisos;
• efectos;
• errores;
• idempotencia;
• reversibilidad;
• observabilidad;
• condiciones de uso.

Los agentes pueden elegir herramientas permitidas, pero los contratos, las políticas y el software determinista protegen los efectos.

MCP y FastMCP pueden ofrecer una forma común de exponer herramientas a agentes. Las APIs, los conectores y los eventos integran el sistema con la operación empresarial.

09 — Recuperar el trabajo cuando algo falla

Los fallos forman parte del diseño operativo.

Una aplicación puede no responder. Un evento puede llegar dos veces o fuera de orden. Una autorización puede caducar. Un modelo puede producir una salida inválida. Una acción puede completarse técnicamente sin conseguir su objetivo.

Diseñamos rutas para:

• validar antes de actuar;
• reintentar operaciones seguras;
• evitar duplicados;
• compensar cuando existe una acción inversa;
• conservar un estado consistente;
• escalar con contexto;
• declarar un caso parcial o pendiente;
• registrar qué ocurrió;
• indicar qué queda por hacer.

La recuperación preserva la evidencia del fallo y la convierte en información para operar y mejorar.

10 — Verificar el resultado

Cada operación necesita una fuente o señal que permita comprobar su efecto.

Ejemplos:

• el ERP muestra el nuevo estado;
• un documento ha sido validado y asociado al caso;
• un servicio externo confirma la transacción;
• la persona responsable acepta el resultado;
• una conciliación coincide;
• el pedido llega a la siguiente etapa;
• una máquina observa que el objeto está en la posición esperada.

La verificación puede necesitar una lectura posterior, una señal independiente o una comprobación física.

Una operación termina cuando el efecto esperado puede observarse o el caso queda situado en un estado explícito. El criterio de finalización pertenece al diseño desde el principio: permite construir métricas útiles y distinguir actividad de resultado.