La inteligencia artificial en iluminación no empieza con elegir un modelo. Empieza con una decisión concreta: qué tarea queremos mejorar, qué datos la describen, qué error podemos tolerar y quién responde cuando la máquina se equivoca.
Esa es la diferencia entre una prueba útil y una demo convincente. La primera reduce trabajo o mejora una decisión que ya podemos observar. La segunda produce una salida plausible, pero no demuestra que sea correcta, mantenible ni rentable.
En este artículo uso “IA” como un término paraguas. Bajo él caben reglas y automatizaciones, analítica de datos, modelos de clasificación o detección y sistemas generativos. Separarlos es importante: no tienen las mismas entradas, explicaciones, controles ni responsabilidades.
La pregunta correcta no es “¿dónde puedo poner IA?”
Antes de hablar de herramientas, escribí el problema en una frase verificable:
- “Tardamos demasiado en localizar una luminaria o un driver que falla.”
- “Tenemos fichas técnicas en PDF y necesitamos encontrar datos comparables sin copiar valores a mano.”
- “Recibimos consultas repetitivas sobre compatibilidad, regulación o montaje.”
- “Queremos detectar consumos o comportamientos anómalos en una instalación conectada.”
- “Necesitamos adaptar el control a ocupación, horarios o condiciones de uso.”
Después definí qué decisión cambiaría. ¿Una persona revisará antes un documento? ¿Mantenimiento priorizará una inspección? ¿El sistema propondrá una escena que luego aprobará el responsable? Si no podés describir la decisión y el criterio de aceptación, todavía no hay un caso de uso: hay curiosidad por la tecnología.
Automatización, analítica e IA generativa no son lo mismo
Automatización: ejecutar una regla conocida
Una automatización sigue instrucciones explícitas: si ocurre A, hacé B. Por ejemplo, apagar un grupo fuera del horario definido, enviar una alerta cuando un dispositivo no responde o rellenar una plantilla con campos ya identificados.
Puede ser muy valiosa y no necesita aprendizaje automático. De hecho, una regla simple suele ser preferible cuando el comportamiento esperado está claro, se puede probar y el motivo de cada acción debe quedar registrado.
Analítica: convertir datos en información para decidir
La analítica resume y relaciona datos. Puede mostrar horas de funcionamiento, comparar consumos, detectar una lectura anómala o clasificar incidencias. Un modelo puede participar en la detección o predicción, pero el resultado sigue dependiendo de qué se midió, con qué frecuencia, con qué contexto y contra qué línea de base.
Un panel que muestra que una luminaria no responde no es lo mismo que un sistema que diagnostica por qué falló. Y un diagnóstico probable no es una orden de sustitución. Cada salto añade supuestos que hay que comprobar.
IA generativa: producir una salida plausible
Un sistema generativo puede redactar una respuesta, resumir un pliego, extraer una tabla, transformar una consulta o proponer código. Su fortaleza suele estar en acelerar una primera versión o una búsqueda, no en convertirse automáticamente en fuente de verdad.
Puede inventar una referencia, confundir una variante, mezclar unidades o presentar con seguridad algo que no verificó. Para documentación técnica, la salida debe contrastarse con el documento original, las fichas vigentes, los planos, las normas aplicables, los cálculos y las pruebas.
Regla práctica: si una tarea puede resolverse con una regla determinista, empezá por la regla. Usá analítica o un modelo cuando exista una variabilidad real que aporte valor medible. Usá generación cuando el resultado sea revisable y el coste de una propuesta incorrecta esté controlado.
Qué casos tienen una base técnica razonable
Hay evidencia pública de investigación y programas sobre IA aplicada a sistemas integrados de edificios, incluidos la iluminación, el control, la monitorización, la detección y diagnóstico de fallos y la optimización. El programa AI Building Systems Innovation (AIBSI) de NIST describe ese ámbito de investigación. El proyecto AI-Optimized Building Controls de NIST presenta contexto de control, optimización y evaluación en testbeds.
El Departamento de Energía de Estados Unidos, en su artículo sobre optimización de sistemas de iluminación, trata el uso de controles adaptativos y optimización. También recoge la relevancia de sensores y diagnóstico la información de Sensors and Fault Detection, de DOE/PNNL.
Estas fuentes demuestran que existen líneas de investigación, demostraciones y marcos de trabajo. No demuestran que cualquier producto comercial consiga el mismo resultado, ni que exista un ahorro, una precisión o una autonomía universal. Esa distinción debe aparecer en cualquier propuesta.
1. Documentación y datos de producto
Es un buen primer terreno porque la entrada y la salida pueden acotarse:
- recibís un PDF, una tabla o un conjunto de fichas autorizadas;
- extraés modelo, potencia, flujo, dimensiones, control, temperatura de color u otros campos;
- conservás la página y el fragmento de evidencia;
- una persona valida la variante, la unidad, la condición y la vigencia;
- publicás solo los registros aceptados.
La IA puede ayudar a encontrar y ordenar información. No debe completar silenciosamente un dato ausente ni convertir una inferencia en una especificación. “No declarado” es una salida válida; inventar un valor no lo es.
2. Búsqueda y soporte interno
Un asistente puede localizar una sección de un manual o preparar una respuesta a una consulta repetitiva. Para que sea útil, debe responder con documentos autorizados, indicar la fuente y reconocer cuándo no encuentra evidencia.
Una respuesta generada no debería cambiar por sí sola una configuración, aprobar una sustitución ni interpretar una exigencia normativa. El flujo seguro es buscar → citar → revisar → responder.
3. Detección y diagnóstico de anomalías
En instalaciones con sensores y registros consistentes, un modelo puede ayudar a señalar comportamientos que merecen atención: pérdida de comunicación, lecturas fuera de patrón o diferencias entre zonas comparables.
La alerta no es el fallo. Puede deberse a un sensor desplazado, una actualización, un cambio de uso, una escena mal configurada, una red interrumpida o una condición que el modelo no conocía. El técnico necesita contexto, acceso a la instalación y autoridad para confirmar o descartar.
4. Control adaptativo y optimización
La investigación de NIST y DOE/PNNL muestra que el control adaptativo y la optimización son áreas reales de trabajo. En operación, sin embargo, hay que demostrar que la estrategia respeta niveles de iluminación, confort, horarios, accesibilidad, seguridad, límites del equipo y preferencias del usuario.
Un control que persigue una métrica aislada puede empeorar otra. Optimizar consumo sin observar calidad de iluminación, disponibilidad, quejas o mantenimiento no es optimizar el sistema: es mover el problema.
5. Apoyo al diseño
La IA generativa puede ayudar a ordenar requisitos, comparar alternativas ya documentadas, redactar una memoria inicial o crear una lista de comprobación. También puede servir para explorar opciones conceptuales.
No debe presentarse como cálculo luminotécnico, coordinación BIM validada, selección final de producto ni comprobación de cumplimiento. La responsabilidad sigue necesitando planos, datos de producto, cálculos, criterios de diseño, revisión y documentación de cambios.
Dónde falla o no compensa
Datos pobres producen decisiones pobres
Un modelo no corrige automáticamente un inventario incompleto. Revisá, como mínimo:
- identidad de luminaria, driver, sensor y controlador;
- unidades y convenciones consistentes;
- fecha, versión y procedencia de cada registro;
- cobertura de espacios, horarios y condiciones de uso;
- valores ausentes, duplicados y cambios de firmware;
- permisos para usar y compartir los datos.
La calidad debe medirse para el caso concreto. Una colección de PDFs puede ser suficiente para buscar títulos y completamente insuficiente para comparar prestaciones entre variantes.
La salida puede ser convincente y estar equivocada
La fluidez del texto no es evidencia. En una propuesta generativa, exigí citas o referencias localizables, marcá incertidumbres y compará una muestra con la fuente primaria. En una predicción o detección, separá falsos positivos de falsos negativos y prestá especial atención a los errores peligrosos.
La AI Risk Management Framework de NIST organiza la gestión en Govern, Map, Measure y Manage. Sus características de confiabilidad incluyen validez y fiabilidad, privacidad, seguridad y resiliencia, además de transparencia y responsabilidad; se explican en la guía de características confiables. Es un marco para ordenar el trabajo, no una garantía de resultados.
Para sistemas generativos, el NIST AI RMF Generative AI Profile añade riesgos propios de la generación. La consecuencia práctica es sencilla: documentar el contexto, medir el comportamiento observado y gestionar el ciclo de vida.
La privacidad no se arregla después
Antes de subir un archivo a un servicio externo, identificá qué contiene: nombres, correos, planos, direcciones, credenciales, topología de red, imágenes, hábitos de ocupación, contratos o información de clientes. Minimizá los datos, anonimizá cuando sea posible y verificá finalidad, retención, acceso, ubicación y condiciones del proveedor.
La guía del ICO sobre IA y protección de datos aporta orientación sobre exactitud, gobernanza y protección de datos en el contexto del Reino Unido. No reemplaza el asesoramiento aplicable a tu jurisdicción, pero ayuda a formular las preguntas correctas.
CISA recomienda en su guía sobre seguridad de datos para sistemas de IA no introducir información sensible en servicios de IA que no sean confiables. Tratá cualquier entrada como potencialmente expuesta hasta demostrar lo contrario.
Ciberseguridad y operación son parte del caso de uso
Si la IA lee o modifica un sistema conectado, agregá al análisis:
- inventario de activos, interfaces y dependencias;
- identidad, permisos mínimos y separación de funciones;
- segmentación de red y gestión de secretos;
- registros de decisiones, cambios y accesos;
- actualización, copia de seguridad y recuperación;
- comportamiento seguro cuando el modelo, la red o el proveedor no están disponibles.
Las Directrices de CISA y NCSC para el desarrollo seguro de sistemas de IA sitúan la seguridad en el ciclo de vida, no únicamente en la puesta en producción. En iluminación, eso implica que un sistema debe tener un modo de operación conocido cuando el servicio inteligente falla. El fallback no puede ser “esperar a que vuelva la nube”.
Un caso de uso bien acotado
Tomemos la clasificación de consultas sobre productos, sin automatizar respuestas finales.
Entrada: consultas recibidas y un conjunto cerrado de fichas y manuales vigentes.
Salida: categoría sugerida, documento y página de apoyo, nivel de confianza y estado “requiere revisión”.
Revisión: una persona confirma que la respuesta corresponde al modelo y la variante correctos, corrige la clasificación y decide qué se envía al cliente.
Fallback: si falta evidencia, hay documentos contradictorios o la consulta afecta seguridad, compatibilidad o conformidad, se deriva a un especialista sin generar una respuesta automática.
Métrica: tiempo de primera clasificación, cobertura de consultas, tasa de correcciones y número de errores relevantes. Compará contra el proceso actual con una muestra definida; no uses una cifra inventada ni una demo seleccionada.
Este diseño es más modesto que un “experto automático”, pero es auditable. También permite detener la prueba si el ahorro de tiempo no compensa la revisión, la integración, la licencia, la formación y el mantenimiento.
La revisión humana tiene que ser real
Revisar no es pulsar “aceptar” sin leer. La orientación del ICO sobre revisión humana destaca que la revisión debe ser significativa: la persona necesita competencia, información suficiente y autoridad para cuestionar o anular el resultado.
Definí antes:
- quién revisa y qué conocimientos necesita;
- qué evidencia debe consultar;
- qué errores obligan a escalar;
- quién puede rechazar una recomendación;
- cómo queda registrada la decisión;
- qué ocurre cuando el revisor no tiene suficiente información.
La experiencia profesional no es un adorno colocado al final del flujo. Es parte del diseño del sistema.
Cómo evaluar una prueba pequeña
Usá una muestra representativa y congelá sus reglas antes de mirar el resultado. Registrá:
- Problema: qué decisión y qué proceso se quieren mejorar.
- Entrada: origen, permisos, calidad, versión y límites de los datos.
- Salida: formato, evidencia, incertidumbre y acciones permitidas.
- Métrica: tiempo, cobertura, exactitud, correcciones, coste y errores peligrosos.
- Supervisión: responsable, autoridad, doble revisión si corresponde y trazabilidad.
- Fallback: procedimiento manual y comportamiento ante datos faltantes o indisponibilidad.
- Mantenimiento: quién actualiza documentos, reglas, modelo, integraciones y criterios.
- Coste total: preparación de datos, integración, uso, soporte, formación, auditoría y retirada.
No confundas precisión en una muestra cómoda con rendimiento en producción. Probá variantes, documentos antiguos, datos incompletos, unidades ambiguas, fallos de comunicación y preguntas fuera de alcance. Un caso negativo bien elegido puede enseñar más que una colección de aciertos.
Checklist: continuar, rediseñar o no automatizar
Continuar una prueba
- El problema y la decisión están escritos en términos observables.
- La entrada está autorizada, versionada y suficientemente completa.
- La salida incluye evidencia y no oculta incertidumbre.
- Hay una métrica y una comparación con el proceso actual.
- Los errores peligrosos tienen un tratamiento explícito.
- Existe una persona competente con autoridad para corregir o rechazar.
- El modo manual sigue funcionando si falla la IA.
- El coste de operar y mantener el sistema está presupuestado.
Rediseñar antes de continuar
- El modelo responde bien solo con ejemplos seleccionados.
- Nadie sabe qué documento o dato originó una respuesta.
- La clasificación mezcla modelos, variantes o unidades.
- La métrica premia una cosa y perjudica otra.
- El flujo depende de un proveedor sin plan de salida.
- La revisión existe en el procedimiento, pero no en el tiempo ni en el presupuesto.
No automatizar esa decisión
- La salida no puede verificarse con la documentación o una prueba.
- Un error puede comprometer seguridad, conformidad o funcionamiento y no existe revisión competente.
- Para obtener el dato habría que enviar información sensible a un servicio no evaluado.
- Una regla determinista resuelve el problema con menos complejidad.
- El supuesto beneficio no supera integración, mantenimiento y dependencia.
La conclusión: menos magia, mejores decisiones
La IA puede ser útil en iluminación cuando reduce una tarea repetitiva, hace visible una anomalía o ayuda a explorar una alternativa sin esconder sus límites. La investigación pública de NIST y DOE/PNNL confirma que hay trabajo serio en optimización, controles, sensores y diagnóstico de sistemas de edificios; no convierte cada promesa comercial en evidencia de rendimiento.
La disciplina consiste en separar lo que está demostrado de lo que se afirma, y la asistencia de la autonomía. Definí el problema, cuidá los datos, medí errores, protegé la información, prepará el fallback y reservá la decisión final para quien tiene contexto y responsabilidad.
La pregunta que conviene llevar a la próxima reunión no es “¿qué modelo usamos?”. Es: “¿qué decisión mejora, con qué evidencia, bajo qué límites y quién puede decir que no?”
Lecturas relacionadas
También te puede interesar
Para explorar