DashAI en Chile: cómo probar modelos de IA con datos propios

Una herramienta chilena para experimentar con modelos

El 7 de agosto de 2026, CENIA difundió la presentación de DashAI, una plataforma de código abierto cuyo desarrollo fue liderado por la Facultad de Ciencias Físicas y Matemáticas de la Universidad de Chile, mediante DCC e IDIA. La publicación describe una interfaz gráfica para entrenar y evaluar modelos, con ejecución en el computador del usuario y sin dependencia obligatoria de servicios en la nube. CENIA, presentación de DashAI.

Para una empresa chilena, nuestra lectura es que esta alternativa facilita una exploración acotada: comprobar si los datos disponibles contienen señales útiles para una tarea. El punto de partida puede ser una tabla histórica de operación y una pregunta que alguien necesite resolver. El resultado esperado de esa primera exploración es evidencia para decidir si vale la pena continuar.

Convertir una necesidad en una pregunta comprobable

Consideremos una empresa de soporte técnico hipotética. Quiere identificar, al cerrar una solicitud, cuáles podrían reabrirse durante los treinta días siguientes, para ofrecer una comprobación adicional al cliente. El área de servicio tendría que definir qué cuenta como reapertura: volver a tratar el mismo problema, por ejemplo. Una solicitud nueva sobre otro equipo no debería etiquetarse automáticamente igual.

Proponemos preparar una fila por solicitud, con datos disponibles al cierre y una etiqueta que indique si después se reabrió dentro del período acordado. Solo incluiríamos casos cuyo plazo de observación ya terminó; una solicitud cerrada ayer todavía no permite conocer ese resultado. El ejemplo describe un diseño de evaluación, no una implementación ni resultados de Digital Dev.

Separar los datos para no anticipar la respuesta

La documentación de DashAI permite seleccionar columnas de entrada y de salida, y distribuir los datos entre entrenamiento, validación y prueba. Ofrece divisiones predefinidas, aleatorias o por índices de filas. Estas opciones permiten configurar el experimento; corresponde al equipo elegir una separación que represente el uso futuro. DashAI, entrenamiento de un modelo.

La guía de scikit-learn explica que usar información que no estaría disponible al predecir puede producir evaluaciones demasiado optimistas. También indica que las transformaciones que aprenden de los datos deben ajustarse con el conjunto de entrenamiento, manteniendo aparte la prueba. scikit-learn, errores habituales y fuga de información.

En nuestra empresa de soporte, excluiríamos la fecha de reapertura y las gestiones posteriores al cierre de las variables de entrada. Proponemos reservar un período posterior para la evaluación final y revisar que registros duplicados de una misma solicitud no aparezcan a ambos lados de la separación. De lo contrario, el ensayo podría beneficiarse de información que no tendría al atender solicitudes nuevas.

Comparar con una referencia sencilla y revisar los errores

DashAI recomienda incluir un clasificador de referencia, como Dummy Classifier, junto con los modelos evaluados. Su interfaz permite observar resultados de entrenamiento, validación y prueba. Esa referencia aporta una comparación inicial antes de atribuir valor a un algoritmo más complejo. DashAI, recomendaciones de entrenamiento.

Supongamos, solo para ilustrar, que en una muestra de mil solicitudes hay cincuenta reaperturas. Una regla que siempre prediga que no habrá reapertura acertaría en las otras novecientas cincuenta: 95% de exactitud, sin detectar ninguna de las cincuenta que interesaban. Son números ficticios que muestran por qué conviene mirar qué errores se cometen, además del porcentaje global de aciertos.

Para el caso propuesto, pediríamos al equipo comparar cuántas reaperturas detecta cada alternativa y cuántas revisiones adicionales genera sobre casos que no se reabren. También contrastaríamos el resultado con una regla operativa sencilla acordada por servicio. La selección debería considerar la capacidad de realizar esas revisiones y la utilidad de las alertas, usando validación para elegir y dejando la prueba final reservada.

Comprobar qué exige operar en un equipo propio

El repositorio oficial ofrece instaladores de escritorio que ejecutan los modelos con CPU y detalla requisitos de sistema y procesador. Para aceleración con GPU indica otra vía de instalación y configuración. La elección del equipo y del modelo influye, por tanto, en cómo se organiza el ensayo. DashAI, requisitos e instalación.

Nuestra propuesta es registrar versión de la herramienta, configuración, tiempo de ejecución y equipo utilizado. La ejecución local tampoco resuelve por sí sola quién puede acceder al archivo, dónde se conserva una copia o qué componentes se autorizan. Para comenzar, usaríamos una muestra controlada con los campos necesarios para la pregunta y accesos definidos. El presupuesto debe incluir preparación, revisión y mantenimiento, además de los recursos de cómputo.

Decidir qué justifica pasar a un piloto operativo

Al terminar, proponemos reunir la definición de reapertura, el período analizado, las variables utilizadas, la separación de datos y los errores de cada alternativa. Si el resultado depende de una columna poco confiable o cambia mucho entre períodos, el siguiente trabajo puede estar en mejorar el registro de la operación. Esa conclusión también es útil para orientar una inversión.

Si la comparación resulta prometedora, el siguiente paso podría ser un piloto donde una persona revise las alertas antes de contactar clientes. Habría que diseñar además la integración, el seguimiento de errores y la posibilidad de detener el flujo. Nuestra guía de autonomía de agentes aborda las acciones posteriores a una predicción; la página de IA aplicada a empresas conecta esas decisiones con el alcance de un proyecto.