Seguí intentando arreglar el modelo. El problema era la luz.

El primer número que puse en la pizarra para esta construcción fue 97 por ciento. El segundo fue 14.

Describen el mismo modelo. En el ejemplo de estampado de nuestra investigación, un modelo de visión validado al 97% de precisión en el laboratorio llega a una prensa de troquel progresivo de 200 toneladas que corre a 40 golpes por minuto y empieza a rechazar en falso el 14% de las piezas buenas. Nada dentro del modelo cambió. Lo que cambió fueron las entradas: el deslumbramiento de las luces del pabellón que se desplaza con el ángulo del golpe, el lubricante que se acumula de forma distinta en troqueles calientes que en fríos, las primeras 50 piezas de cada turno fabricadas antes de que la prensa alcance el equilibrio térmico. La física de la línea sacó las imágenes de la distribución en la que se validó el modelo, y ningún modelo, con cualquier precisión, es fiable ahí fuera.

Dediqué el último tramo de este proyecto a construir una demo que toma esa frase en serio. Se llama Inspection Trust Gate, y puedes verla decidir, pieza a pieza, en veriprajna.com/es/demos/ia-en-el-borde-para-la-inspeccion-de-calidad-en-fabricacion-inspection-trust-gate. No es un mejor modelo de defectos. Es la capa de runtime entre el modelo de visión y el actuador de rechazo del PLC, y su único trabajo es decidir, para cada pieza, si el veredicto del modelo es seguro para actuar.

Lo que sigue es la historia de la construcción a través de los tres momentos que cambiaron cómo pienso sobre la IA de inspección: un evento de deriva a las 06:00 programadas, un número de benchmark que me negué a creer, y una regla que casi eliminé.

La solución no es un mejor modelo

Resistí esa frase más tiempo del que debí. Cuando un detector se comporta mal, cada instinto que tengo como constructor dice reentrenarlo, mejorar el backbone, comprar más etiquetas. La investigación se negó a cooperar. Los sistemas AOI listos para usar rechazan en falso entre el 5 y el 15% de las piezas buenas, y los bien afinados bajan del 2%, lo que nuestra página de solución llama "un problema de calibración y de datos, no un problema de arquitectura del modelo". La misma investigación reporta que el 84% de los proyectos de integración de sistemas fallan o fallan parcialmente, y que en un despliegue típico de inspección el trabajo de integración es el 60% del calendario del proyecto mientras el entrenamiento del modelo es el 15%. La línea que no dejaba de releer: "El hardware es una orden de compra."

Así que hice algo que se sintió ligeramente herético: hice que el modelo de defectos de la demo fuera deliberadamente poco notable. Es una distancia kNN a textura conocida como buena, un sustituto estilo PatchCore-lite, y obtiene un AUROC de 0.845 separando piezas buenas limpias de defectuosas en el split de prueba retenido MVTec AD metal_nut (fotografías reales de piezas manufacturadas reales, etiquetas públicas). No oculto ese número y no lo estoy vendiendo. En producción ese hueco lo ocupa tu pipeline de NVIDIA Metropolis, tu sistema Cognex, tu modelo a medida, detrás de una interfaz fija. El producto es la capa alrededor del motor, no el motor.

La capa empieza con una pregunta que ninguna métrica de precisión responde: ¿está esta imagen dentro de las condiciones de captura en las que se validó el modelo? El EnvelopeDetector de la demo calcula una distancia de Mahalanobis en el espacio de señales físicas (exposición, contraste, rango dinámico, un proxy de foco, detalle de alta frecuencia, tinte térmico de color, saturación, fracción de deslumbramiento), ajustado sobre las 220 imágenes de entrenamiento conocidas como buenas y nada más. Cuando una pieza cae fuera de esa envolvente validada, la puerta deja de confiar por completo en la salida del modelo, por muy seguro que el modelo se sienta al respecto.

Incluso un modelo perfecto solo es válido en entradas dentro de su envolvente validada.

Esa es la frase de la que cuelga toda la construcción. La deriva es un fallo de entrada, no un fallo del modelo, y un fallo de entrada nunca aparece en tu panel de precisión. Aparece en tu contenedor de desechos.

¿Qué pasa a las 06:00?

El momento en el que más confío de toda la demo es una marca de tiempo. La app reproduce un turno programado determinista en la estación "Line 3 - metal_nut press," transmitiendo fotografías reales de MVTec AD metal_nut por todo el pipeline. A mitad de camino, un marcador cruza la pantalla: "SHIFT CHANGE 06:00 - cold dies, bay lights on." Entonces llegan 12 piezas buenas corrompidas con deslumbramiento, desenfoque y tinte térmico. Quiero ser preciso sobre qué es eso: las fotografías son reales, la deriva es una corrupción de imagen honesta aplicada a ellas, y la app lo etiqueta como tal. No tenía una línea de estampado que filmar, y fingir lo contrario envenenaría todo el sentido.

Lo que ocurre después es la razón de que exista la demo. El monitor de envolvente se pone en rojo. La puerta lee cada pieza desviada como fuera de la envolvente validada y se niega a dejar que el veredicto del modelo toque el actuador. Veredicto tras veredicto vuelve HOLD, enviado a la cola de escalamiento para un humano, mientras el panel de al lado muestra lo que una AOI ingenua sin chequeo de envolvente habría hecho con la misma imagen: REJECT.

La primera vez que vi llenarse la cola, hice clic en una pieza retenida esperando ver una vaga excusa de "anomalía detectada". En cambio el monitor de envolvente descompuso la ruptura señal por señal, porque lo había construido a partir de mediciones físicas en lugar de embeddings, y las mediciones físicas pueden explicarse a sí mismas. En una pieza desviada, el brillo se sitúa a 7.6 sigma del ajuste validado y aporta el 87.1% de la distancia de Mahalanobis al cuadrado. Eso no es un modelo teniendo una sensación. Eso es una lectura de instrumento.

Al final de la fase de deriva el marcador es contundente. La línea base ingenua ha desechado automáticamente 12 piezas buenas. El Trust Gate ha desechado automáticamente cero, reteniendo todas ellas para revisión. Las mismas imágenes, el mismo modelo de defectos sustituto, los mismos umbrales en la puntuación de defectos. La única diferencia es que un camino verificó la entrada antes de confiar en la salida.

La línea base ingenua y la puerta vieron las mismas piezas y el mismo modelo. La única diferencia fue el permiso para actuar.

Sobre esa cifra en dólares, porque aquí es donde las demos suelen empezar a mentir: el panel extrapola la tasa medida de falso rechazo ingenua a un turno completo (40 golpes por minuto durante 8 horas son 19,200 piezas) a $2.42 por pieza desechada. Los $2.42 son un orden de magnitud con fuente, anclado a un caso publicado de un fabricante de galletas donde una reducción del 8.7% de desperdicio por desecho ahorró $94K al año y 38,800 kg de producto. No es el número de un cliente, y el contador está etiquetado como proyección en todas partes donde aparece. Yo medí los falsos rechazos; proyecté los dólares; la UI dice cuál es cuál.

Una cosa más que comprobé antes de creer mi propia historia de deriva: las piezas defectuosas inyectadas durante la fase de deriva siguen siendo capturadas o escaladas, nunca auto-aprobadas. En todo el split retenido esa cifra es 93 de 93. Retener piezas buenas no vale nada si las malas se cuelan en el caos.

¿Mi chequeo de envolvente estaba corrigiendo su propio examen?

El número de benchmark en el que más desconfié fue mi mejor número propio. Cuando corrí por primera vez el script del bench, el detector de envolvente separó las imágenes desviadas de las limpias esencialmente a la perfección. Mi reacción inmediata no fue orgullo. Fue sospecha, porque yo había construido ambos lados del examen: escribí las corrupciones de deslumbramiento, desenfoque y tinte térmico, y elegí las señales físicas que vigila el detector. Claro que un detector de deslumbramiento atrapa deslumbramiento. Un revisor con dientes llamaría a eso circular, y tendría razón.

Así que dejé una familia de deriva completamente fuera. El detector nunca se afinó contra la subexposición, nunca la vio durante el desarrollo. Luego volví a ejecutar bench.py (más recientemente el 2026-07-17) en el split de prueba retenido MVTec AD metal_nut: 22 piezas buenas, 93 defectuosas, ajuste de entrenamiento solo sobre las 220 imágenes buenas. En la familia de subexposición retenida, el detector de envolvente obtuvo AUROC 1.000. Ese es el número que sostiene la tesis, precisamente porque se ganó en un modo de fallo para el que nunca lo diseñé. El script imprime "THESIS HOLDS" solo si los números medidos realmente respaldan la afirmación; lo escribí así para que el marketing no pudiera desviarse de la medición.

El resto del benchmark merece su alcance exacto, así que aquí está sin redondear a mi favor. En piezas buenas desviadas, la línea base ingenua sin envolvente rechaza en falso del 95.5 al 100% por familia de deriva (deslumbramiento 100%, desenfoque 100%, tinte térmico 100%, subexposición 95.5%, promediando 98.9%). El Trust Gate rechaza en falso el 0.0% de ellas, reteniendo todas para revisión. Y la salvedad honesta: las corrupciones están a plena fuerza, así que el colapso de la línea base es casi total por construcción. La afirmación que defenderé es la dirección, que un modelo limpiamente validado se derrumba una vez que las entradas salen de su envolvente, no el porcentaje particular. Estas son mediciones en un benchmark de investigación bajo deriva sintética. No son garantías de mundo abierto, y cualquiera que las cite como rendimiento en producción las está usando mal, yo incluido.

La regla que casi eliminé

La decisión de honestidad más difícil que tomé en esta construcción fue sobre una regla que apenas funciona. Al principio añadí una regla de zona geométrica: localizar la anomalía en una cuadrícula gruesa de 8 por 8, y tratar un defecto dentro de la zona funcional de forma distinta a una mancha en el borde cosmético. Suena a metrología real. Luego la medí, y las mediciones fueron humillantes. El proxy de rugosidad local localiza una anomalía en 33 de 93 defectos retenidos, alrededor del 35%. Cambia el resultado de la puerta en exactamente 1 de 93. Y 0 de los 18 auto-rechazos están respaldados por una anomalía localizada real; cuando nada se localiza, el centroide cae por defecto al centro de la cuadrícula, que se lee como dentro de zona por defecto.

Me quedé con tres opciones. Eliminar la regla y fingir que nunca lo intenté. Conservarla y dejar que la UI implique una metrología de precisión que no tengo. O conservarla y hacer que la interfaz confiese. Elegí la confesión. Cuando el defecto estrella de la demo se auto-rechaza (pieza test-flip-264, un defecto estructural grosero real de la clase flip de MVTec), el desglose de geometría declara abiertamente que nada se localizó en esta pieza y el rechazo se apoya solo en la confianza de textura.

La regla se gana el puesto exactamente una vez, e hice que la app lo demostrara en lugar de escenificarlo. Al arranque, la demo busca entre los 93 defectos retenidos una pieza con una anomalía genuinamente localizada fuera de la zona funcional en una pieza por lo demás confiada. En el split enviado esa búsqueda encuentra test-flip-251, centroide en fila 2, columna 6, y la puerta la envía a HOLD en lugar de disparar el actuador. Si los datos cambiaran y ninguna pieza calificara, ese momento simplemente no aparecería. Incluso hice A/B testing del umbral sigma de la regla con validación cruzada de 5 pliegues; el valor ajustado no mostró mejora sobre el 2.5 fijado a mano, así que conservé 2.5 y registré el resultado negativo en el repo con "shipped": false. En un compromiso de producción esta regla se reemplaza por metrología con precisión de píxel anclada en CAD. En la demo es un sustituto honesto, y la UI lo dice en cada pieza.

Una capa de confianza que se sobrevende a sí misma es una contradicción en los términos.

Esa línea se convirtió en una regla de diseño. Si toda la promesa del producto es saber cuándo no confiar en un modelo, no puede a la vez farolear sobre su propio componente más débil.

Los agentes aconsejan, el código decide

La decisión que me niego a delegar es la que mueve metal. La puerta misma es código determinista llano, fuera de cualquier LLM y también fuera del modelo de visión. Sus umbrales se ajustan a partir de los propios datos de la demo, no a ojo: auto-aprobación por debajo de 0.948 y auto-rechazo por encima de 1.30 en la escala de confianza calibrada, con todo lo intermedio, y todo lo fuera de envolvente, yendo a HOLD. Corre contra un presupuesto duro de ventana de golpe de 750 ms, y en el log de auditoría enviado las decisiones aterrizan en decenas de milisegundos: test-good-288 auto-aprobado en 37.7 ms, test-good-289 en 24.4 ms, y el log del actuador de rechazo para test-flip-264 dice "REJECT actuated in 25ms (budget 750ms)."

Debo ser claro sobre qué actúa: nada, todavía. El camino EtherNet/IP hacia un actuador de rechazo Allen-Bradley ControlLogix es un simulador que registra exactamente lo que habría hecho, y el sumidero MES es un stub que escribe la línea de trazabilidad que habría escrito. Ambos están etiquetados como stubs en la app. Están moldeados como los adaptadores reales porque la realidad OT (plantas mixtas Siemens y Allen-Bradley, una ventana de rechazo medida en milisegundos) es la superficie real del producto, pero una demo que implicara una línea en vivo fallaría su propia prueba de confianza.

Hay agentes en el sistema, y los acoté a propósito. Cuando las piezas se acumulan en la cola de escalamiento, un par Drift Triage se pone a trabajar: un agente de diagnóstico lee las desviaciones de señales físicas ordenadas por ranking a través de las piezas retenidas y propone una hipótesis de causa raíz con una acción recomendada, y un agente crítico luego comprueba esa hipótesis contra la evidencia numérica, rebajándola a "investigación manual" si la señal citada no es realmente la desviación dominante. Están construidos sobre Pydantic AI y son intercambiables de proveedor, y sin una API key configurada todo degrada a un triaje plantillado determinista, así que la demo corre totalmente offline. Lo que los agentes no pueden hacer, por construcción, es tocar el actuador. Para cuando hablan, la puerta ya ha decidido.

Los agentes aconsejan, el código decide.

Cada una de esas decisiones deja un recibo. Cada pieza escribe un registro de linaje JSONL: id de pieza, estación, model id metalnut-defect-knn version v7, dataset hash ae95b5b533c8, confianza de defecto, puntuación OOD, las señales físicas, qué reglas de la puerta se dispararon, latencia contra el presupuesto de 750 ms, las líneas de log de actuación y MES, lo que la línea base ingenua habría hecho, y la etiqueta de riesgo high-risk:quality-gate (EU AI Act Annex III, eff. 2026-08-02). Un clic exporta el turno como inspection_audit.jsonl.

El reloj regulatorio importa aquí. Las obligaciones de alto riesgo del EU AI Act se vuelven plenamente aplicables el 2 de agosto de 2026, las decisiones de calidad críticas para la seguridad están en el Annex III, y las multas máximas llegan a €35M o el 7% del volumen de negocio global por las violaciones más graves de prácticas prohibidas. Quiero ser cuidadoso con mis palabras, porque exactamente aquí importan las palabras cuidadas: la demo no está certificada bajo el EU AI Act, y ninguna demo puede estarlo. Lo que muestra es linaje listo para el EU AI Act, un registro por decisión diseñado para ser evidencia archivable en un expediente de conformidad de alto riesgo, generado a velocidad de línea en lugar de reconstruido después de un incidente.

¿Qué sobrevive a la siguiente actualización del modelo?

La pregunta que no dejaba de hacerme mientras construía esto fue brutal para un creador de demos: si el siguiente modelo de defectos del cliente es dramáticamente mejor que mi sustituto, ¿sigue importando algo de esto? Ahora creo que eso es exactamente al revés. Deloitte predice que la adopción de IA agéntica en manufactura subirá del 6% al 24% en 2026 (Deloitte), lo que significa más modelos y más autonomía llegando a más actuadores. Cada uno de esos modelos tendrá una envolvente validada, y la física de una línea de prensa (deslumbramiento, troqueles fríos, equilibrio térmico) seguirá sacando las entradas de ella. Un modelo perfecto no cambia nada de eso, porque el fallo que la puerta previene es un fallo de entrada, y la obligación de auditoría a la que sirve es legal, no de modelado. El filtrado por deriva, la procedencia y la actuación gobernada se sostienen a cualquier precisión del modelo. Esa es la propiedad que me convenció de que esta capa, y no otro modelo, era lo que valía la pena construir; el turno programado en veriprajna.com/es/demos/ia-en-el-borde-para-la-inspeccion-de-calidad-en-fabricacion-inspection-trust-gate es mi intento de dejarte ver cómo se gana esa afirmación pieza a pieza.

Y si preferirías verlo antes que leerme describirlo, aquí está el corte del fundador, de principio a fin.

Así que la pregunta que haría sobre cualquier modelo de inspección en tu línea, incluido uno del 97%, no es "¿qué tan preciso es?". Es: para la pieza que acaba de cruzar la cámara, ¿sabes si esa imagen estaba dentro de la envolvente en la que se validó el modelo? Si no puedes responder por pieza, en milisegundos, con un registro que podrías entregar a un auditor, entonces no creo que tengas un problema de precisión. Creo que tienes un problema de envolvente, y genuinamente me gustaría saber cuál tiene tu línea.