Una planta no está preparada para implementar IA solo porque tenga un historiador, un SCADA moderno o una demostración convincente de un proveedor. Para esta guía, una planta está preparada para implementar IA cuando puede formular una pregunta operativa concreta, encontrar la evidencia que la sostiene, mantener una frontera de seguridad y asignar a una persona la responsabilidad de tomar la decisión que la IA no puede tomar. (NIST, hoja de ruta 2026; NIST AI RMF).
Este artículo propone una heurística editorial de ocho dimensiones. Cada dimensión recibe 0, 1 o 2 puntos, pero la suma no convierte el resultado en una certificación. Un cero en el caso de uso, en la evidencia accesible, en la frontera de seguridad o en la existencia de un responsable humano bloquea el piloto aunque el total sea alto. El método sirve para decidir qué hay que investigar; no sustituye una evaluación de riesgos, una revisión de seguridad funcional, un análisis de ciberseguridad ni asesoría legal.
La hoja de ruta 2026 de NIST sobre IA y fabricación inteligente sitúa entre los retos pendientes los datos industriales complejos, la integración con sensores y controles heterogéneos y la operación fiable y explicable en entornos de alto impacto. (NIST, hoja de ruta 2026) NIST también describe que la analítica de fabricación tiene que transformar datos de procesos en conocimiento útil para decisiones, y que la integración con adquisición de datos y soporte a decisiones sigue siendo una barrera. (NIST, Data Analytics for Smart Manufacturing Systems).
1. Empieza por una decisión de planta que pueda observarse
El primer filtro no es “¿qué modelo podemos comprar?”. Es “¿qué decisión concreta queremos preparar mejor y cómo sabremos que la respuesta ayudó?”. Una pregunta válida tiene un objeto y un momento: explicar por qué una línea se detuvo, priorizar una revisión de mantenimiento, reunir la evidencia de una desviación o preparar una comparación de parámetros dentro de un procedimiento aprobado. “Usar IA para optimizar la fábrica” no permite delimitar datos, responsables ni una condición de parada.
La pregunta debe tener un dueño del resultado, aunque la IA solo entregue una vista o una recomendación. También necesita una referencia de cómo se trabaja ahora. Si el supervisor tarda una hora en reconstruir un evento, el piloto puede medir el tiempo de revisión y el número de registros que hay que reconciliar. Si el objetivo es detectar una desviación, hay que definir qué se considera evento, qué registros confirman que ocurrió y quién decide la respuesta. El resultado no tiene que ser una mejora; demostrar que la ayuda no añade valor es un resultado útil.
NIST llama a esto una medición guiada por operaciones: para evaluar el rendimiento hace falta caracterizar el sistema y establecer un marco de referencia contra el que comparar. (Operations-driven Performance Measurement for Smart Manufacturing Systems) La idea protege al equipo de una trampa frecuente: medir la precisión de un modelo sin medir si cambió la decisión que motivó el proyecto.
Como lectura complementaria para delimitar la decisión, consulta la hoja de ruta 2026 de NIST.
El trabajo de Li, Cheng, Møller y Lee revisa problemas de datos de IA industrial a lo largo del ciclo de vida y propone unir características de los datos con las necesidades del modelo, junto con prácticas de gestión. (artículo revisado por pares, Computers in Industry, 2025) El artículo no ofrece una receta universal para una planta concreta. Sí ayuda a formular una pregunta menos ingenua: ¿qué datos y qué conocimiento experto necesita esta tarea, y qué parte puede verificarse antes de construir un modelo?
Como lectura complementaria sobre datos de proceso y decisiones, consulta Data Analytics for Smart Manufacturing Systems.
Para puntuar esta dimensión: 0 significa que el caso se expresa como una tecnología o una ambición sin decisión observable; 1, que existe una pregunta pero no una referencia, un responsable o un criterio de éxito verificable; 2, que el equipo ha escrito la decisión, el alcance, la referencia, el responsable y la condición de parada. Un cero aquí bloquea el piloto. Antes de seguir, redacta una ficha de una página con el evento, la decisión humana, los sistemas incluidos y los datos que podrían probarlo.
2. Comprueba si los datos pueden sostener una respuesta, no solo una gráfica
La cantidad de datos no resuelve su falta de significado. Para revisar un evento industrial suelen hacer falta un identificador estable del activo o lote, marcas temporales comparables, unidades, estado operativo, fuente de origen, versión del procedimiento y una forma de distinguir medición, alarma, observación humana y decisión autorizada. La lista exacta depende de la pregunta. Un conjunto mínimo para analizar paradas no es el mismo que para revisar calidad de un lote.
Un registro que dice “temperatura 82” no basta si no sabemos en qué equipo, con qué unidad, en qué zona de operación, con qué calidad de señal y durante qué estado de producción se capturó. La analítica de NIST describe un bucle en el que el sistema modela, capta, transmite, analiza, comunica y actúa sobre datos; si el significado se pierde en el cruce, el resultado puede parecer preciso y ser inútil para la decisión (NIST Data Analytics).
Conviene auditar unas pocas muestras antes de hablar de entrenamiento. Toma eventos conocidos y comprueba si el mismo activo conserva su identidad entre PLC, SCADA, historiador, MES, mantenimiento y calidad. Revisa saltos de reloj, cambios de unidad, huecos, duplicados, estados de máquina y campos que solo existen en la memoria de un operador. Una muestra pequeña no prueba que todo el histórico sea fiable, pero descubre pronto si el piloto depende de una reconciliación manual que nadie ha asumido.
El artículo de Li y sus coautores identifica problemas distribuidos en siete etapas del ciclo de vida de los datos y señala que la preparación debe tener en cuenta el modelo y también los datos de sensores en tiempo real y el conocimiento de expertos (Li et al., 2025). Es una razón para incluir al personal que conoce el proceso en la auditoría. No para convertir una opinión en etiqueta verdadera, sino para registrar qué significa una señal, qué excepciones existen y qué evidencia puede contradecirla.
Para ampliar la comprobación de comparabilidad, consulta Operations-driven Performance Measurement.
Puntúa 0 si no puedes localizar muestras relevantes o si los datos dependen de una fuente inaccesible; 1 si las muestras existen pero tienen huecos de contexto, calidad o linaje que requieren investigación; 2 si hay un inventario acotado, acceso autorizado, contexto documentado y una persona que puede corregir o retirar datos defectuosos. La evidencia accesible es un bloqueo independiente: un total alto no compensa que el equipo no pueda abrir, interpretar o revisar la fuente de una afirmación.
Para profundizar sin repetir este diagnóstico, consulta Datos industriales con contexto. Allí el foco es cómo enlazar registros, procedimientos y eventos; aquí la pregunta es si ese contexto está disponible para el primer piloto.
3. Mapea el contexto antes de pedir a la IA que relacione señales
Una IA no descubre automáticamente qué significa una etiqueta de planta ni qué procedimiento prevalece. Puede encontrar correlaciones o reunir documentos, pero necesita que el equipo defina relaciones y límites. ¿Qué activo pertenece a qué línea? ¿Qué versión de la receta estaba vigente? ¿Qué alarma describe un estado y cuál requiere una respuesta? ¿Qué registro de calidad puede bloquear una liberación? Si no se contestan estas preguntas, el piloto puede producir una respuesta fluida que mezcla objetos distintos.
El contexto también incluye el estado operativo. Una vibración durante el arranque no tiene la misma lectura que la misma vibración en régimen; una nota de mantenimiento puede confirmar que alguien intervino, pero no que la intervención eliminara la causa. La salida debe mostrar la fuente, la marca temporal o versión, el objeto al que se refiere y el límite de lo que el registro permite concluir. Si la IA no puede presentar ese rastro, su resultado es una pista para investigar, no evidencia para autorizar un cambio.
OPC UA Part 1 define una infraestructura común para intercambiar información industrial, incluyendo modelos de información, mensajes, transferencia y conformidad; su alcance abarca sensores, actuadores, controles, MES y ERP. (OPC Foundation, Part 1) Eso no significa que cualquier instalación OPC UA esté lista para IA. Un protocolo puede transportar una variable; no decide si la variable es la correcta, si su servidor está autorizado o si la aplicación puede escribir en un endpoint.
Como referencia adicional sobre el recorrido de los datos, consulta NIST Data Analytics.
La comprobación útil es un mapa de evidencia para un caso acotado. Elige un activo o familia de producto y escribe sus nombres en cada sistema, el origen de cada campo, las transformaciones aplicadas y el procedimiento que define su interpretación. Separa hechos medidos, hipótesis, observaciones y decisiones. Si dos fuentes se contradicen, conserva el conflicto y asigna quién lo resuelve. Borrar la discrepancia para obtener un conjunto de datos limpio produce una falsa sensación de preparación.
Para ampliar el mapa de datos y conocimiento experto, consulta la revisión de Li et al. (2025).
Puntúa 0 si el equipo no puede explicar qué objeto representa cada señal o qué fuente tiene autoridad; 1 si existe un mapa parcial y quedan alias, versiones o estados sin resolver; 2 si el alcance, el linaje, las relaciones y los conflictos están documentados para la pregunta. Esta dimensión se diferencia de “datos” porque una fuente disponible puede seguir sin tener contexto suficiente.
El artículo sobre integración IT/OT explica las fronteras entre sistemas de planta y sistemas empresariales. En esta lista de comprobación, esa frontera importa como límite de interpretación: integrar más sistemas no sustituye a decidir qué relación es válida.
4. Diseña la integración IT/OT como una frontera que se pueda cerrar
En una planta, OT incluye sistemas y dispositivos que supervisan o cambian procesos físicos. NIST SP 800-82 Rev. 3 insiste en que la protección de OT tiene que considerar sus requisitos de rendimiento, fiabilidad y seguridad, además de amenazas y vulnerabilidades. (NIST SP 800-82 Rev. 3) Por eso una primera integración de IA debe tener una ruta aprobada, una finalidad definida y una forma de retirar el acceso sin dejar un estado inseguro.
En muchos pilotos tiene sentido empezar con lectura controlada: la aplicación consulta una copia o un servicio autorizado y no escribe en PLC, SCADA, DCS ni lógica de seguridad. No es una regla universal ni una autorización automática. Si la tarea exige enviar comandos, cambiar una receta, suprimir una alarma o modificar una consigna (setpoint), deja de ser una prueba de análisis y requiere revisión de ingeniería, seguridad funcional, ciberseguridad y gestión del cambio con la autoridad correspondiente.
La guía conjunta de CISA y otras agencias sobre inventario de activos OT recomienda construir un inventario y una taxonomía con información de los componentes del sistema. (CISA, Foundations for OT Cybersecurity: Asset Inventory Guidance) Para el piloto, inventaría las interfaces o endpoints, propietarios, rutas, permisos, dependencias, versión y método de cierre. Registra también qué sistema conserva el proceso original si el modelo queda fuera de servicio.
Puntúa 0 si la ruta toca control físico sin aprobación, si se desconoce el inventario o si nadie puede cerrar el acceso de forma segura; 1 si existe una ruta propuesta pero falta validar segmentación, permisos, rendimiento o reversibilidad; 2 si el flujo está aprobado, es acotado, auditable y puede retirarse sin alterar el proceso operativo. Un cero en la frontera de seguridad bloquea el piloto, incluso si la aplicación solo pretende “ayudar”.
La integración no debe confundirse con el tema de por qué SCADA, histórico, MES y ERP discrepan. Allí se analiza el intercambio entre capas; aquí la pregunta previa es si el intercambio necesario puede autorizarse y cerrarse.
5. Define seguridad, gobierno humano y adopción antes de probar
La seguridad del piloto tiene dos planos. El primero es técnico: identidad, permisos, segmentación, registros, protección de datos y gestión de vulnerabilidades. El segundo es operativo: qué pasa si la salida es incorrecta, llega tarde, deja de actualizarse o induce a actuar fuera del procedimiento. El AI RMF de NIST es voluntario y de uso general; organiza la gestión en gobernar, mapear, medir y gestionar, y pide considerar la confianza durante el diseño, el desarrollo, el despliegue, el uso y la evaluación. (NIST AI RMF) En planta, eso se traduce en controles y responsables concretos, no en una etiqueta de “IA responsable”.
El gobierno humano debe estar escrito en términos observables. Una persona con autoridad puede revisar la fuente, interpretar la salida, ignorarla, escalar una anomalía y detener el sistema. Tiene que conocer sus límites y conservar la vía de trabajo existente. No basta con poner “revisión humana” en una presentación si el turno no dispone de tiempo, acceso o autoridad para ejercerla.
La adopción tampoco equivale a impartir una formación inicial. Comprueba quién verá la salida, en qué momento del turno, qué acción cambiará y quién mantiene las reglas cuando cambia el producto o el procedimiento. Si el operario necesita copiar valores a una hoja paralela, el piloto está generando trabajo oculto. Si el responsable de seguridad no puede revisar logs o retirar el acceso, la asignación de responsabilidades está incompleta.
El Reglamento (UE) 2024/1689, conocido como AI Act, clasifica determinados sistemas como de alto riesgo, incluidos ciertos componentes de seguridad sujetos a legislación de armonización, y establece requisitos sobre gestión de riesgos, transparencia, precisión, robustez, ciberseguridad y supervisión humana según el caso. (EUR-Lex, Reglamento (UE) 2024/1689) La clasificación depende del sistema, del producto y del uso. Este artículo no determina si una instalación concreta está dentro de una categoría legal ni sustituye el análisis jurídico.
Puntúa seguridad con 0 si no hay controles ni un límite de uso; 1 si hay controles previstos pero no probados o responsabilidades ambiguas; 2 si la ruta, los accesos, los logs, el procedimiento de incidente y el mecanismo de parada están probados dentro del alcance. Puntúa gobierno humano con 0 cuando nadie tiene autoridad; 1 cuando hay un nombre pero no tiempo, competencia o circuito de decisión; 2 cuando la función, la autoridad, la formación y la revisión están documentadas. Puntúa adopción con 0 si el flujo no encaja en el trabajo; 1 si encaja solo con apoyo del equipo del proyecto; 2 si el turno puede usarlo y cuestionarlo sin depender de una persona excepcional.
Para no mezclar planos, revisa también límites de capacidades de la IA en planta. Ese artículo trata qué puede y no puede afirmar un asistente; esta sección convierte esa cautela en un control de operación.
6. Puntúa la operación continua y decide el siguiente alcance
La última prueba es incómoda porque llega después de la demo. ¿Quién mantiene los conectores? ¿Quién detecta un cambio de esquema, una deriva de sensor, una actualización de procedimiento o una caída de calidad? ¿Con qué frecuencia se revisa el rendimiento? ¿Dónde quedan los logs y cómo se conserva la evidencia de una decisión? Una salida correcta el día uno no prueba que el sistema siga siendo adecuado cuando cambia el producto, el turno o la fuente.
ISO/IEC 42001:2023 especifica requisitos para establecer, implementar, mantener y mejorar continuamente un sistema de gestión de IA en una organización. (ISO/IEC 42001) Es un estándar de gestión; no es una certificación automática del modelo ni una prueba de seguridad OT. El AI Act también prevé gestión de riesgos durante el ciclo de vida para sistemas de alto riesgo, pero su aplicación depende del alcance legal y del papel de cada actor. (EUR-Lex, artículo 9)
Para operar un piloto, define una ficha de mantenimiento: fuentes y propietarios, frecuencia de actualización, pruebas de calidad, umbrales de revisión, registro de cambios, soporte, retirada y criterio de escalado. Mide lo que el caso necesita: tiempo de revisión, registros reconciliados, falsos avisos, incidencias, excepciones y decisiones de parada. No conviertas una puntuación del modelo en sustituto de una métrica de planta.
La decisión puede expresarse en cuatro líneas. Suma las ocho dimensiones, pero aplica primero los bloqueos. De 0 a 5 puntos, vuelve a fundamentos: pregunta, evidencia, contexto y límites. De 6 a 11, limítate al descubrimiento o a una prueba acotada de solo lectura, con revisión y sin autonomía. De 12 a 16 puntos, puedes evaluar un piloto acotado, nunca autonomía ni cambios de control por defecto. (NIST SP 800-82 Rev. 3) Para pasar de un alcance a otro hace falta evidencia adicional; la banda no concede permiso.
| Dimensión | 0 puntos | 1 punto | 2 puntos |
|---|---|---|---|
| Caso de uso | No hay decisión observable | Pregunta sin referencia o dueño claro | Decisión, referencia, dueño y parada definidos |
| Datos | Muestras inaccesibles o irrelevantes | Hay muestras con huecos | Acceso, contexto, calidad y responsable |
| Contexto | Señales sin objeto o autoridad | Mapa parcial | Relaciones, linaje y conflictos documentados |
| Integración IT/OT | Ruta insegura o desconocida | Diseño sin validar | Ruta aprobada, acotada y reversible |
| Seguridad | Sin controles ni límite | Controles incompletos | Controles, logs, incidente y retirada probados |
| Gobierno humano | Nadie decide | Responsable sin autoridad suficiente | Autoridad, competencia y revisión documentadas |
| Adopción | No encaja en el turno | Depende del equipo del proyecto | Flujo usable y que el turno puede cuestionar |
| Operación continua | Nadie mantiene ni retira | Mantenimiento previsto | Soporte, cambios, revisión y retirada asignados |
La puntuación es una herramienta para una conversación de ingeniería y operaciones. No mide conformidad, madurez corporativa ni seguridad de una instalación. Si la planta no puede probar una premisa, el resultado correcto es investigar o detenerse. Para revisar un caso concreto con WizeeMind, hablemos sobre la pregunta, la evidencia disponible y los límites del primer piloto.
Preguntas frecuentes
¿Qué significa que una planta esté preparada para implementar IA?
Significa que puede probar un caso de uso concreto con datos accesibles, contexto suficiente, una frontera OT segura, una persona responsable y un método para revisar resultados, detener la prueba y conservar el proceso original. La puntuación de este artículo es una heurística editorial, no una certificación. (NIST AI RMF)
¿Hay que instalar sensores nuevos antes de probar IA en una planta?
No siempre. Primero conviene comprobar qué registros existentes responden a la pregunta, qué contexto les falta y si una medición nueva cambiaría la decisión. Un sensor nuevo puede aportar evidencia, pero no corrige por sí solo una pregunta mal definida ni una ruta de integración insegura.
¿Qué datos mínimos hacen falta para un piloto de IA industrial?
No existe un conjunto universal. Como mínimo deben poder identificarse la variable o evento, el activo o lote, la marca temporal, la unidad y el estado operativo, además de la fuente, la calidad y el responsable que puede corregir o retirar el dato. La lista final depende del caso de uso.
¿Cómo se conecta la IA a un PLC o SCADA sin poner en riesgo la operación?
El primer piloto debe usar una ruta aprobada y preferentemente de solo lectura, con inventario de activos, segmentación, autenticación, registro y una frontera clara que impida a la IA cambiar el control sin autorización específica. Un cambio en PLC, SCADA, receta o consigna (setpoint) requiere una evaluación propia.
¿Cuándo puede una planta escalar un piloto de IA?
Solo cuando la prueba ha respondido a la pregunta con evidencia repetible, tiene responsable operativo y de datos, mantiene los límites de seguridad y puede sostener el trabajo de actualización, revisión, soporte y retirada en el siguiente alcance. Un buen resultado local no autoriza por sí solo ampliar a otra línea.
¿ISO/IEC 42001 o el AI Act garantizan que el proyecto sea seguro?
No. ISO/IEC 42001 define requisitos para un sistema de gestión de IA y el AI Act fija obligaciones según el sistema y su uso. Ninguno sustituye la evaluación específica de OT, seguridad de proceso, datos, personas y legislación aplicable, ni convierte una puntuación editorial en conformidad. (ISO/IEC 42001; EUR-Lex, AI Act)