Seleccionar página

Sep 22, 2026 | REVISTA

✦ Quién responde cuando decide la máquina

Isaac Bosch

Fundador y CEO de eComm360

Orquestar inteligencia artificial en un proceso industrial es, antes que un ejercicio de tecnología, un ejercicio de sistema de gestión.

Un agente revisa cada día los albaranes de recepción, compara lo pedido con lo servido y abre incidencia al proveedor cuando la desviación supera el umbral establecido. Funciona. Lleva ocho meses funcionando y ha reducido a la mitad el tiempo de cierre de las reclamaciones.

Entonces llega la auditoría. Y la pregunta no es si funciona.

La pregunta es quién decidió que aquella desviación concreta, la del 14 de marzo, no merecía incidencia.

La respuesta honesta —lo decidió el modelo— no sirve. No porque sea falsa, sino porque no es auditable.

 

Dónde empieza el control

El uso de inteligencia artificial en la empresa se despliega en tres niveles, y no todos tienen las mismas implicaciones para quien responde de la calidad de un proceso.

El primero es la productividad personal: redactar, sintetizar, traducir. Nadie audita el resumen de una reunión.

El segundo es la automatización de procesos: eliminar pasos manuales y el copiar y pegar improductivo entre pantallas. Aquí la eficiencia se vuelve medible, y con ella aparece la primera obligación de control.

El tercero es la transformación: ejecutar acciones que antes eran inviables por coste o por tiempo. En ese nivel la gobernanza deja de ser un requisito añadido y pasa a ser la condición que permite que el proceso exista.

Buena parte de las organizaciones que creen estar en el segundo nivel están en realidad en el primero, repetido muchas veces por muchas personas. Y esa distinción importa, porque el momento en que un modelo deja de asistir a alguien y empieza a actuar sobre el proceso es exactamente el momento en que entra en el alcance del sistema de gestión.

 

Automatizar no es orquestar

Automatizar es ejecutar una tarea con una regla determinista. Si el stock baja de veinte unidades, lanzar propuesta de pedido. Entrada conocida, regla explícita, salida reproducible. Eso se audita desde hace décadas: se documenta la regla, se verifica la ejecución, se archiva el registro.

Orquestar es encadenar varios componentes —modelos, servicios, bases de datos, personas— para resolver un proceso completo donde cada paso aplica criterio, no solo regla. Un componente interpreta la petición del cliente, otro consulta disponibilidad, otro valora si la excepción de plazo es aceptable, otro redacta la respuesta.

La salida ya no es reproducible en sentido estricto. Con los mismos datos de entrada, dos ejecuciones pueden diferir.

Ahí deja de encajar el control clásico. No porque el sistema sea peor, sino porque el registro de que el procedimiento se cumplió ya no demuestra que la decisión fuera correcta.

 

Quién decide, quién ejecuta, quién registra

El principio no es nuevo: es la separación de funciones de toda la vida, aplicada a componentes que no son personas.

Un agente que propone una acción no debería ser el mismo que la aprueba, ni el mismo que la registra. Cuando toda la cadena vive dentro de una única herramienta que recibe, decide, ejecuta y documenta su propio resultado, se ha construido un proceso sin control interno. Da igual lo bueno que sea el modelo.

Una orquestación bien planteada responde tres preguntas en cada paso: qué componente formula la propuesta, qué componente o persona la autoriza, y dónde queda constancia independiente de ambas cosas.

Y una cuarta, que suele faltar: quién es el propietario del proceso.

La responsabilidad no se delega en el modelo. Se delega la ejecución. La responsabilidad sigue teniendo nombre y apellidos, y ese nombre debe estar escrito antes de la primera ejecución automática, no después del primer incidente.

 

La evidencia no es el registro de actividad

Muchas implantaciones guardan la salida del agente y dan por cubierta la trazabilidad. No lo está.

Cuando dentro de dieciocho meses haya que reconstruir por qué se tomó una decisión, la salida sola no explica nada. Hace falta el estado completo del momento: qué datos se consultaron y en qué versión estaban, qué instrucciones recibió el modelo, qué versión del modelo se utilizó y con qué umbral se descartaron las alternativas.

Ese penúltimo punto merece atención. Los proveedores actualizan sus modelos con frecuencia y sin aviso relevante para el cliente. Un cambio de versión es un cambio de proceso: mismo procedimiento documentado, comportamiento distinto. Si el sistema de gestión no trata esa actualización como un cambio sujeto a control, tiene un proceso que muta solo.

De ahí se deriva un riesgo que rara vez se documenta: la dependencia de un proveedor único. Una caída de servicio o un cambio de política contractual pueden dejar un proceso crítico sin ejecución. La continuidad exige tener previsto un camino alternativo —otro modelo, una implantación propia o el retorno controlado al procedimiento manual— y haberlo probado antes de necesitarlo.

Con un proceso determinista, si falta evidencia se puede volver a ejecutar y comprobar. Con un sistema orquestado, no siempre. La evidencia hay que capturarla en el momento. 

El calendario se ha movido; la exigencia, no

El Reglamento Europeo de Inteligencia Artificial alcanza su fecha de aplicación general el 2 de agosto de 2026. Las obligaciones para sistemas de alto riesgo se han aplazado, pero las de transparencia del artículo 50 no: obligan también a las empresas que despliegan sistemas de IA, no solo a quienes los fabrican.

Conviene leer bien lo que ese aplazamiento significa. Se ha movido el calendario. No la arquitectura de la norma. La organización que use el retraso para posponer el diseño de sus controles acabará diseñándolos con prisa y bajo presión externa, que es la peor forma de construir un sistema de gestión.

 

El coste que descarta proyectos: el re-control

Los modelos generan contenido incorrecto con apariencia de correcto. Es una característica del funcionamiento, no una avería, y obliga a definir un protocolo de verificación para toda salida que alimente una decisión.

De ahí sale el criterio de descarte más útil que conozco: si el esfuerzo de verificar el resultado iguala al de haber hecho la tarea, el caso de uso no es viable.

Quien viene del control de procesos reconocerá el patrón. Un proceso que necesita inspección al cien por cien de lo que produce no está controlado, está contenido. La automatización que exige revisar cada salida no ahorra trabajo: lo desplaza.

Por eso el control humano no se coloca en todas partes ni en ninguna, sino donde el cruce de dos variables lo justifica. La primera es la reversibilidad: reclasificar un artículo del catálogo se deshace en un minuto; confirmar una fecha a un cliente, bloquear un lote o lanzar una orden de compra, no. La segunda es la fiabilidad demostrada sobre una muestra medida, no estimada.

De ese cruce salen tres decisiones que conviene documentar: el umbral a partir del cual el agente escala a una persona, el criterio de parada que detiene la cadena ante un caso fuera de rango, y el circuito de excepción para lo que el sistema no sabe resolver.

Un sistema orquestado sin criterio de parada no es autónomo. Es un sistema sin frenos. 

 

La disciplina ya estaba inventada

La implantación de IA no exige teorías nuevas. Exige aplicar con rigor el pensamiento de mejora continua a un entorno digital.

Orden y limpieza antes de procesar. Un modelo alimentado con datos sucios no produce errores aislados: produce desperdicio automatizado, a escala y con apariencia de rigor. Antes de conectar nada hace falta una ontología del dato, es decir, saber qué significa cada campo, quién lo mantiene y con qué frecuencia se actualiza.

Síntesis antes de inversión. Si el proceso y su solución no caben en una página, no está entendido. Y lo que no está entendido no está listo para automatizarse.

Mejora incremental frente a proyecto faraónico. Automatizar pequeños flujos de forma constante rinde más que esperar dos años a una plataforma integral que llega tarde y sin adopción.

Y una advertencia específica de este terreno: existen tareas que, resueltas en superficie, generan dos desviaciones nuevas aguas abajo. El indicador del proceso automatizado mejora mientras el conjunto empeora. Suelen esconderse en los proyectos de alto impacto y alto esfuerzo, que son precisamente los que más ilusión generan en un comité. 

 

Antes de automatizar, puntuar

Ninguna acción entra en producción sin pasar una evaluación previa, del mismo modo que ningún proveedor entra en la cadena de suministro sin homologación.

Ocho componentes bastan para esa evaluación: proceso afectado, dolor operativo real, frecuencia, disponibilidad y calidad de los datos, resultado esperado, forma de medirlo, esfuerzo de implantación y riesgos identificados. De ahí sale una puntuación.

Por encima de ocho sobre diez, el caso es sólido y puede iniciarse de inmediato. Entre cinco y siete, hay que replantear el alcance o limpiar los datos antes de invertir. Por debajo de cinco, no merece los recursos, por atractiva que suene la idea.

La medición posterior se sostiene sobre cuatro indicadores: tasa de intervención humana, tasa de reversión de las acciones automáticas, tiempo de ciclo y tasa de error frente a la línea base anterior. Sin línea base no hay mejora demostrable, solo impresión de mejora.

El segundo indicador es el más revelador. Un agente cuyas acciones se corrigen a menudo no está fallando en silencio: está avisando de que el punto de control está mal situado. 

 

Mi posición

La conversación sobre inteligencia artificial en la empresa industrial ha girado demasiado tiempo alrededor de qué modelo elegir. Es la pregunta menos determinante.

La que decide el resultado es otra: qué decisiones estamos dispuestos a delegar, con qué control, y cómo demostramos después que fueron las correctas.

Una buena analogía es la bicicleta eléctrica. El motor permite llegar más lejos y con menos desgaste, pero quien pedalea y quien decide la dirección sigue siendo la persona. Si suelta el manillar, el problema no será del motor.

El día que un auditor pregunte quién tomó una decisión, la respuesta útil no es el nombre de una tecnología. Es el nombre de un proceso, el de quien responde de él, y la evidencia que lo sostiene.

Revista

Lo + nuevo

✦ La movilidad que empieza antes del viaje

Durante años, los desplazamientos profesionales se han gestionado como una cuestión esencialmente operativa. Había que llegar a una reunión, mover equipos entre sedes, coordinar una visita comercial o facilitar el acceso al centro de trabajo. Esa lógica sigue siendo...

leer más

Lo último

Noticias

CALIDAD
EXCELENCIA DE GESTIÓN
INNOVACIÓN
MEDIOAMBIENTE
RSE
SOCIAL MEDIA
CAPITAL HUMANO
EVENTOS
  SÍGUENOS

Recibe nuestra newsletter

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR
Aviso de cookies