La respuesta corta
Un peritaje asistido por visión por computador no sustituye al perito: le quita el trabajo administrativo y le deja el criterio. El modelo pre-clasifica lo que ve en la foto, propone una estimación y prepara el informe; la persona confirma, corrige o rechaza.
Y el problema principal no es el modelo. Es la captura: una foto mal hecha invalida cualquier inferencia, por buena que sea la red. El segundo problema es qué hace el producto cuando el modelo no está seguro — que es más a menudo de lo que sugiere cualquier demo.
Qué hace realmente el modelo, y qué no
Sirve bien para tareas acotadas y verificables:
- Detectar y clasificar elementos en la imagen: qué hay y dónde.
- Estimar magnitudes a partir de referencias conocidas en la escena.
- Comparar contra un estado anterior, cuando existe una foto previa del mismo bien.
- Marcar incoherencias: fotos que no corresponden al expediente, duplicados, imágenes reutilizadas.
No sirve —y prometerlo es de donde salen los proyectos fallidos— para emitir una valoración final sin supervisión, ni para decidir sobre daños ocultos que no aparecen en la imagen.
Ese matiz debe estar escrito en el alcance: el modelo propone, el perito dispone. Cambia la responsabilidad, el diseño de las pantallas y la conversación regulatoria.
En el dispositivo o en el servidor
La inferencia en el propio teléfono tiene ventajas concretas y medibles. Con Core ML, el modelo se ejecuta localmente y aprovecha automáticamente el hardware disponible —CPU, GPU y el Neural Engine—, con dos consecuencias que importan en este caso de uso:
- Privacidad: los datos no salen del dispositivo, lo que simplifica mucho la conversación de protección de datos cuando la foto es del domicilio de un asegurado.
- Latencia: sin viaje de red, el resultado es inmediato — imprescindible si el modelo tiene que guiar la captura mientras el perito apunta con la cámara.
Los tamaños típicos van de kilobytes a decenas de megabytes, y se convierten desde TensorFlow, PyTorch o scikit-learn, entre otros. Eso hace viable llevarlo dentro del paquete de la app.
El criterio práctico:
| Ejecuta en el dispositivo | Ejecuta en el servidor |
|---|---|
| Guiado de captura en tiempo real | Modelos grandes que no caben en el binario |
| Sitios sin cobertura | Cuando el modelo cambia semanalmente |
| Datos que prefieres no mover | Cuando necesitas auditar cada inferencia centralmente |
| Respuesta inmediata | Cuando la inferencia se combina con datos de negocio |
Y una combinación que suele ganar: guiado y filtrado en el dispositivo, valoración en el servidor. Lo local evita fotos inservibles; lo central mantiene la trazabilidad.
La captura es el 80 % del resultado
Antes de invertir en el modelo, invierte en cómo se hacen las fotos:
- Guía en pantalla que indique distancia, encuadre y qué debe aparecer.
- Rechazo inmediato de fotos movidas, oscuras o desenfocadas, en el momento, no al enviar el expediente.
- Referencia de escala cuando hay que estimar dimensiones.
- Secuencia obligatoria: si el informe necesita cinco vistas, la app las pide una a una y no deja continuar sin ellas.
Un flujo de captura bien diseñado mejora los resultados más que un modelo mejor. Y es mucho más barato.
El caso «no sé»
Aquí se decide si el producto es útil o es un juguete. Un modelo devuelve una confianza, y el producto tiene que hacer algo distinto en cada tramo:
- Confianza alta: se propone el resultado, el perito confirma con un toque.
- Confianza media: se propone marcado como estimación, con el campo abierto para corregir.
- Confianza baja: no se propone nada. Se pide la entrada manual o más fotos.
El error clásico es enseñar siempre un número. Un valor inventado con apariencia de precisión es peor que un campo vacío, porque la persona lo acepta por inercia y el error entra en el expediente con firma humana.
Y hay que guardar la corrección: cada vez que el perito cambia una propuesta, eso es dato de entrenamiento y es también la métrica de calidad del sistema.
Datos de entrenamiento
- Las fotos de entrenamiento tienen que parecerse a las reales: hechas con prisa, con mala luz, desde ángulos raros y con teléfonos de gama media. Un modelo entrenado con imágenes de catálogo funciona en la demo y falla en el primer día de campo.
- La verdad de referencia la ponen los peritos, y eso es tiempo de personas caras que hay que presupuestar.
- Sesgo geográfico y de tipología: si el conjunto de datos es de una región o de un tipo de bien, el modelo se degrada fuera de ahí.
Qué medir desde el primer día
- Tasa de aceptación sin corrección de las propuestas del modelo.
- Error medio frente al valor final del perito.
- Fotos rechazadas por calidad, y en qué paso.
- Tiempo por expediente, antes y después. Es la métrica que justifica el proyecto.
Sin esa última medida, el proyecto no tiene forma de demostrar su retorno.
Cumplimiento
Un sistema que ayuda a decidir sobre una prestación económica no es un filtro de fotos. Hay obligaciones de transparencia y de supervisión humana que conviene mirar antes de diseñar, no después — lo tratamos en qué cambia el AI Act para tu app.
Y la regla de oro del alcance: si la decisión afecta al dinero que cobra una persona, tiene que haber una persona en el circuito, y tiene que poder explicar por qué.
Cuándo no
- Si no hay volumen. Con pocos expedientes al mes, el ahorro no paga ni la anotación de los datos.
- Si el perito ya va rápido. El cuello de botella puede estar en la coordinación, no en el informe. Merece la pena medirlo antes.
- Si no tienes histórico de fotos con su resultado. Sin datos, esto empieza por un proyecto de recogida, y conviene decirlo desde el principio.
Es el tipo de proyecto que abordamos en apps para el sector seguros, donde la herramienta de campo y el modelo van juntos: sin la primera, el segundo no recibe fotos que pueda usar.
Fuente primaria, consultada el 14 de agosto de 2026: Core ML en la documentación de Apple.
