La clasificación de nubes de puntos es una de las tareas más caras y lentas de cualquier proyecto LiDAR. Cada año mejora lo que la IA puede automatizar — pero también crece la confusión sobre dónde acaba el modelo y dónde empieza el criterio humano.
Qué hace bien la IA hoy
Para las clases mayoritarias — suelo, vegetación, edificación — los modelos actuales alcanzan precisiones muy altas de forma consistente. En proyectos de inspección de líneas eléctricas, la separación entre vegetación, torres y conductores es ya un problema mayoritariamente resuelto a escala de millones de puntos por minuto, incluso en corredores de decenas de kilómetros con cambios de vegetación y orografía notables.
Esto no es casualidad: estas clases tienen patrones geométricos muy consistentes (planaridad del suelo, verticalidad de estructuras, dispersión de la vegetación) que los modelos actuales capturan bien a partir de miles de proyectos previos de entrenamiento. El resultado práctico es que un porcentaje muy alto del corredor no necesita ojo humano en absoluto.
Dónde sigue fallando
Las dificultades aparecen en los bordes: clases minoritarias, objetos ambiguos y zonas de baja densidad de puntos. Un modelo entrenado para un tipo de territorio rinde peor en otro, y los falsos positivos en clases críticas (por ejemplo, ruido confundido con cable) tienen un coste desproporcionado, porque un solo punto mal clasificado en un conductor puede disparar una alarma de vegetación invadiendo la servidumbre que no existe.
Otro punto ciego habitual son las transiciones: el borde entre un tejado y la vegetación que lo roza, o el arranque de un poste desde el suelo. Ahí la geometría es ambigua incluso para un ojo humano entrenado, así que exigirle al modelo una frontera perfecta es pedirle algo que ni el propio dato permite resolver con certeza.
La IA no sustituye al operador. Reordena su trabajo: del etiquetado masivo a la revisión de lo dudoso.
El operador humano no desaparece
El valor del experto se desplaza hacia el control de calidad: validar lo que el modelo marca con baja confianza, corregir los errores sistemáticos y firmar el entregable. Por eso la edición de inconsistencias tiene que estar integrada en el mismo entorno que la clasificación — no en una herramienta aparte que obligue a exportar, corregir y volver a importar, perdiendo contexto y tiempo en cada vuelta.
Esto es exactamente lo que Neobora integra en un único entorno: la clasificación con IA en la nube y la edición de inconsistencias conviven en la misma herramienta, con controles de alta productividad pensados para la precisión en el control de calidad. El operador valida, corrige y firma sin salir de la plataforma ni exportar el dato a un software aparte.
En la práctica esto cambia el perfil del puesto: menos horas de etiquetado repetitivo y más horas de criterio técnico aplicado a los casos que realmente lo requieren. Los equipos que hacen bien esta transición no reducen personal, lo redistribuyen hacia control de calidad, gestión de excepciones y relación con el cliente final.
Un flujo realista
En Neobora el flujo es: clasificación automática en la nube → revisión asistida de zonas de baja confianza → edición puntual → publicación en geoportal. El operador toca solo el porcentaje del dato que de verdad lo necesita, y el resto fluye sin fricción.
Métricas que sí importan
La precisión global de un modelo es la métrica que más se enseña en las demos y la que menos dice sobre el día a día de un proyecto. Dos indicadores son más útiles a la hora de decidir: el porcentaje del corredor que queda marcado como "revisar" tras la clasificación automática, y el tiempo medio de corrección por kilómetro una vez llega a manos del operador.
Un modelo que reduzca la zona de revisión a un 3-5% del total, con una edición ágil sobre ese porcentaje, produce mejores tiempos de entrega que un modelo con una precisión global algo más alta pero que exige revisar el 20% del corredor de forma dispersa e impredecible.
Cómo evaluar a un proveedor
Antes de comprometerse con una plataforma de clasificación, tiene sentido pedir tres cosas concretas: una prueba sobre datos propios (no sobre el dataset de demo del proveedor), visibilidad sobre qué porcentaje del dato queda marcado como dudoso, y acceso a corregir esos casos dentro del mismo entorno sin depender de un ticket de soporte.
Si un proveedor no puede enseñar esas tres cosas con datos reales del cliente, la cifra de precisión que presente en la propuesta comercial vale poco: se mide sobre condiciones que rara vez coinciden con el terreno, la densidad de vuelo o el tipo de infraestructura del proyecto concreto.
En Neobora partimos justo de esas tres exigencias: prueba sobre datos reales del cliente, visibilidad del porcentaje de dato marcado como dudoso y corrección dentro del mismo entorno, sin tickets ni herramientas externas. Preferimos que se nos evalúe con el terreno del proyecto delante, no con un dataset de demostración.
Conclusión
Esperar de la IA una automatización total es la receta para la decepción. Esperar de ella una multiplicación de la productividad del equipo — con el humano en el lazo donde importa, midiendo lo que de verdad predice el tiempo de entrega — es realista hoy mismo. Esa es la apuesta de Neobora.
