Una organización usa inteligencia artificial para anticipar fallas. El sistema recomienda postergar un mantenimiento. Mi pregunta empieza en el paso siguiente: ¿qué convierte esa recomendación en una decisión autorizada sobre un equipo crítico?
El ejemplo muestra la frontera entre una herramienta que informa y un sistema al que se le permite actuar. Esa frontera necesita un responsable, límites claros y evidencia que sobreviva a la decisión.
Qué se está delegando, exactamente
Miraría el recorrido completo. Quién define el objetivo. Qué información recibe el sistema. Quién convierte su recomendación en una orden. Y si puede actuar solo, qué permisos lo habilitan y cuáles le impiden pasarse de su función.
Un mismo modelo puede resumir un documento o intervenir en un proceso del que depende un servicio esencial. Cambian las consecuencias y cambia la evidencia necesaria. La descripción comercial de la herramienta no dice cómo se usa en realidad.
El AI Risk Management Framework del NIST ordena el riesgo en cuatro funciones: gobernar, mapear, medir y gestionar. Lo uso como guía, no como una lista que alcanza con completar para declarar que hay control.
Reconstruir la decisión
Para revisar la postergación buscaría qué datos había en ese momento y de dónde salieron, el estado del equipo y la versión del sistema. También las autorizaciones, los cambios y las excepciones posteriores.
Acá entra la seguridad de la información. Los registros necesitan acceso controlado, protección contra cambios y un tiempo de guarda acorde con su propósito. Guardar información sensible de más también es un riesgo.
La prueba es simple: ¿otra persona competente podría reconstruir lo que pasó? Si una parte depende de recuerdos o de capturas sueltas, hay que dejarlo dicho.
Que alguien pueda frenar a tiempo
Un nombre en un procedimiento es una responsabilidad en el papel. Para saber si funciona, pediría que me muestren qué información tiene esa persona, qué puede cambiar y cuánto tarda en frenar o corregir la acción. Tiene que llegar antes que la consecuencia.
Las guías conjuntas de las agencias de ciberseguridad de Estados Unidos (CISA), Australia (ACSC) y otros países sobre IA en entornos industriales van en la misma línea: limitar lo que la IA controla sin una persona, validar los modelos y conservar la vuelta al control manual o a la automatización convencional.
En el ejemplo, pediría un ensayo con una recomendación errónea: cómo se detecta, cómo se interviene y qué pasa con la operación. Un botón de parada a la vista no demuestra que todo eso funcione.
Cuando cambian los datos o el modelo
Una prueba con datos estables dice poco sobre sensores degradados, información incompleta o un proveedor que cambia el modelo. Revisaría qué variaciones se probaron, qué resultados se aceptaron y qué cambios obligan a repetir la evaluación.
Mantener el servicio en marcha no justifica operar en condiciones inseguras. El plan de continuidad necesita sus propios límites y sus propias pruebas.
La eficiencia se mide en todo el ciclo de vida
La economía circular suma otra pregunta al mismo caso: ¿postergar la intervención alarga la vida útil, o traslada el costo a una falla posterior, a más consumo o a un reemplazo prematuro?
La Ellen MacArthur Foundation estudia cómo la IA puede ayudar al diseño circular, a nuevos modelos de negocio y a cerrar los ciclos de materiales. Ese potencial no prueba el resultado ambiental de una aplicación concreta.
Propongo comparar el antes y el después con datos observados: vida útil, recursos consumidos, piezas recuperadas y residuos. También cuenta lo que consume la propia solución digital. Una mejora parcial se presenta como parcial.
Los escenarios futuros
La discusión sobre la singularidad amplía las preguntas, pero no fija una fecha verificable ni demuestra que una organización haya perdido el control de su IA. El International AI Safety Report 2026 separa los escenarios futuros de pérdida de control de los fallos actuales y reconoce que su probabilidad es incierta. A su fecha de corte, las capacidades observadas no alcanzaban para producirlos.
Lo práctico es revisar hoy el acceso, los permisos y lo crítico del entorno. Los escenarios sirven para prepararse; una conclusión de auditoría se apoya en la evidencia del sistema que se examina.
Dar tiempo a la revisión
Una respuesta rápida también necesita tiempo de revisión. Antes de usarla para decidir, conviene examinar qué entendió el sistema, qué información le falta y qué parte de la respuesta puede sostenerse con pruebas. La fluidez del texto no resuelve esas preguntas.
Pedir criterio exige dar contexto. Por ejemplo, para ordenar una revisión documental hay que explicar qué documentos entran, qué se busca comprobar, qué límites tiene la tarea y quién revisará el resultado. Si esos elementos faltan, la respuesta puede estar bien escrita y servir poco para la decisión.
El tiempo de revisión tiene una función concreta: contrastar la propuesta con la situación real, formular la pregunta que falta y dejar identificada a la persona que puede corregir o detener su uso.
Qué se puede concluir
Antes de darle más autonomía a una herramienta, una organización debería poder mostrar el recorrido completo de una decisión: propósito, datos, permisos, intervención, consecuencias y revisión. El tramo que no puede demostrar marca el límite de la confianza que puede darle al sistema.
Delegar una decisión exige conservar la capacidad de responder por sus consecuencias.
Fernando Arrieta
