Cero fallas en campo, incluso multiplicando volumen

El problema

El fallo en campo de un switchgear es un apagón ajeno con vuestro nombre.

Un fallo en campo no es una devolución de producto de consumo — es riesgo de apagón para el cliente final, penalización contractual y, en el peor caso, pérdida de la cuenta hyperscale. Ese riesgo crece justo cuando la planta multiplica volumen con personal recién incorporado.

• Un fallo en campo no es una devolución: es riesgo de apagón para el centro de datos, penalización contractual y, en el peor caso, la pérdida de la cuenta hyperscale.
• Casi nunca nace de un error único. Es un breaker de un lote dudoso, más una barra del rating anterior, más un apriete que nadie vio, más un FAT documentado con prisa. Ninguno de ellos, por separado, haría saltar una alarma.
• Cada eslabón por separado pasa su control; juntos producen la unidad que falla ya instalada, cuando repararla cuesta mucho más y el cliente lo recuerda durante años.
• Y ese riesgo crece justo cuando la planta multiplica volumen con técnicos recién incorporados y menos tiempo para revisar a mano cada unidad.

Cómo encaja con el sistema IRIS

Cuatro anillos de verificación cruzados — del breaker recibido al dossier final.

Anillo 1 (componente recibido con certificado) + Anillo 2 (unidad configurada y grabada según la orden, validada por visión) + Anillo 3 (defecto detectado antes de cerrar el gabinete) + Anillo 4 (dossier FAT que cruza los tres anteriores). JIDOKA AI bloquea ante cualquier discrepancia; SMED AI acelera el cambio entre configuraciones para no penalizar el ritmo de la rampa.

Ningún anillo resuelve el problema por sí solo: cada uno existe hoy de alguna forma y aun así la unidad defectuosa sale. La fuerza está en el cruce, porque lo que delata la cadena de pequeños fallos es que cuatro fuentes independientes dejen de concordar sobre la misma unidad.

Ver la arquitectura IRIS completa →

Antes y después

Los cuatro anillos del switchgear y qué cierra cada uno

Anillo	De qué casos sale	Qué cierra
1 · Componente recibido	Recepción (7) + aviso de proveedor (3)	Breaker y busbar con certificado, lote a unidad
2 · Configuración y nameplate	Traveler (1) + cambio de rating (10) + nameplate (8)	Celda montada y grabada según la orden
3 · Cierre del gabinete	Cámara de cierre (9) + pinganillo (4)	El defecto que queda dentro del gabinete
4 · Dossier y ensayos	Laboratorio (6) + dossier FAT (11)	Ensayos y fotos cruzados con los tres anteriores
Freno · JIDOKA AI entre anillos	Discrepancia entre anillos	La unidad no avanza hasta resolverla
Cadencia · SMED AI en la rampa	Cambios entre configuraciones	Validar sin frenar la rampa

Riesgo dependiente de disciplina manual en una plantilla que crece rápido → discrepancia detectada dentro de planta, nunca en el cliente.

Estimación de impacto

Estimación de impacto — a validar con vuestros números.

El siguiente bloque es una estimación a validar con los datos concretos de tu planta. Lo planteamos para que el comité tenga un orden de magnitud; lo refinamos en el diagnóstico.

• Payback estimado 6-12 meses frente al primer incidente de campo evitado en un switchgear o UPS ya instalado.
• Protege la relación contractual multianual con el cliente hyperscale, de valor muy superior al de cualquier incidente aislado y del coste directo de reparar la unidad.
• Del riesgo que depende de la disciplina manual de una plantilla que crece rápido a discrepancia detectada dentro de planta, nunca en el cliente, aunque la plantilla siga creciendo.
• Lo validamos con calidad y con quien gestiona la cuenta del cliente, porque el retorno real está en lo que no llega a pasar.

Payback estimado 6-12 meses frente al primer incidente de campo evitado; protege la relación contractual multi-anual con el cliente hyperscale, de valor muy superior al de cualquier incidente aislado. *Estimación a validar con calidad y category management.*

Y la duda razonable del responsable de producción

«¿Hay que tener los doce casos funcionando para empezar?» — no, y plantearlo así es la forma de no empezar nunca. Los anillos se construyen por capas y cada caso paga solo. El cruce entre fuentes que ya están capturadas es tarea anclada, donde los mejores modelos bajan del 1,5% de error [1], y JIDOKA AI para la unidad por discrepancia comprobable, no por una duda del modelo, que sube a una persona.

^[1] Paper OpenAI «Why Language Models Hallucinate», 2025 — sobre fiabilidad de la IA en tareas ancladas.