Articulo de investigación
1Universidad Católica de Cuenca: Cuenca, Azuay, EC-CP 010107
Esta investigación tuvo como objetivo desarrollar un prototipo de aplicación móvil Android capaz de recibir voz o texto en español, traducirlos al quichua mediante un modelo de inteligencia artificial y mostrar una representación visual de señas ecuatorianas asociadas a los términos procesados. La metodología se basó en el marco ágil Scrum organizando el desarrollo en sprints, en conjunto con el análisis de requisitos, el diseño de una arquitectura modular con Flutter y Dart, más la implementación de módulos de reconocimiento de voz y la traducción de palabras con modelos de inteligencia artificial incluyendo el diccionario y simulación de gestos. De esta forma, se propone una herramienta tecnológica que ayude a mejorar la accesibilidad, la inclusión en la comunicación y la preservación del quichua como lengua originaria, y que sirva de base para futuras investigaciones en robótica asistiva y sistemas de traducción automática para lenguajes gestuales.
Palabras clave: Aplicación móvil, discapacidad auditiva., inclusión, inteligencia artificial, lengua de señas ecuatoriana, traducción quichua-lengua de señas.
This research aimed to develop an Android mobile application prototype capable of receiving voice or text in Spanish, translating it into Quichua through an artificial intelligence model, and displaying a visual representation of Ecuadorian sign language associated with the processed terms. The methodology was based on the Scrum agile framework, organizing development into sprints, combined with requirements analysis, the design of a modular architecture using Flutter and Dart, and the implementation of speech recognition and word translation modules through artificial intelligence models, including a dictionary and gesture simulation. Thus, a technological tool is proposed to improve accessibility, communication inclusion, and the preservation of Kichwa as a native language, serving as a foundation for future research in assistive robotics and machine translation systems for gestural languages.
Keywords: Biological monitoring, biotic indices, lower basin, trophic diversity, upper basin.
La discapacidad auditiva es un problema a nivel mundial; ya que hace más difícil comunicarse y relacionarse con los demás. Según la Organización Mundial de la Salud (OMS), 430 millones de personas, necesita rehabilitación por pérdida auditiva y de ellas 34 millones son niños. Además, se calcula que para el año 2050 esta cifra va a superar los 700 millones [1]. La Organización Panamericana de la Salud (OPS) menciona que cerca del 60 % de los casos en niños se deben a causas que se pueden evitar, como infecciones no tratadas, medicamentos que dañan el oído o estar expuesto mucho tiempo a ruidos fuertes [2].
La comunicación humana usa palabras, gestos, expresiones faciales y otros elementos no verbales para transmitir emociones, intenciones y significados. Grillo y Enesi señalan que los gestos, las expresiones faciales y otros recursos visuales complementan al lenguaje oral y son claves en la interacción social [3]. Para las personas con discapacidad auditiva, la lengua de señas es un sistema lingüístico completo que se basa en movimientos de las manos, el cuerpo y la cara. En este contexto, las tecnologías digitales sirven como un apoyo importante para aprender y usar las lenguas de señas; aplicaciones móviles como las descritas por Zhuma Mera et al. muestran que los enfoques lúdicos e interactivos favorecen el aprendizaje autónomo y reducen barreras comunicativas [4].
Sin embargo, las soluciones tecnológicas que existen actualmente tienen varias limitaciones. Por ejemplo, aplicaciones como SINSEÑAS, se enfoca en el aprendizaje y traducción del lenguaje de señas colombiano, depende de imágenes en la pantalla y requieren un procesamiento alto, lo que hace que funcionen mal en celulares de gama baja o en lugares con internet limitado [5]. Existen propuestas que usan tecnologías nuevas, como la realidad aumentada y aplicaciones educativas interactivas, que han hecho más fácil acceder a las lenguas de señas gracias a entornos visuales más dinámicos [6], [7].
No obstante, los avances en inteligencia artificial (IA) han permitido desarrollar sistemas que convierten texto o voz en estructuras que luego pueden asociarse con gestos o representaciones visuales. Dentro de este campo existen modelos multilingües de gran escala, motores neuronales comerciales y arquitecturas basadas en transformadores, cada uno con ventajas y limitaciones distintas [8], [9], [10]. Los modelos multilingües ofrecen una cobertura amplia y resultan útiles cuando se trabaja con idiomas de baja disponibilidad de recursos; sin embargo, su desempeño depende de la calidad del corpus de entrenamiento, de la cobertura lingüística y de la cercanía entre las lenguas involucradas. En el caso del quichua, las dificultades aumentan por la escasez de datasets especializados, la variación regional y el riesgo de obtener traducciones demasiado influenciadas por estructuras del español. Por ello, aunque la traducción automática ha mejorado de manera notable, su aplicación en lenguas originarias todavía requiere validación contextual y revisión humana [8], [9], mientras que, arquitecturas modernas de procesamiento de lenguaje natural, como Transformer, BERT o GPT, dan buenos resultados en tareas de traducción y comprensión [10].
En Ecuador, la inclusión educativa de las personas con discapacidad auditiva necesita mayor atención; puesto que los Datos del Consejo Nacional para la Igualdad de Discapacidades (CONADIS) muestran que hay más de 53 565 personas con discapacidad auditiva, de las cuales 12 001 viven en Tungurahua y 819 están registradas en el sistema educativo nacional [11]. La Constitución de la República del Ecuador refiere que, la educación es un derecho y una obligación importante del Estado, con el fin de garantizar la igualdad y la inclusión social [12]. Por ende, varios estudios destacan el rol de las Tecnologías de la Información y la Comunicación (TIC) para mejorar el aprendizaje y la participación de los estudiantes con discapacidad auditiva [13]. Además, se incluye estrategias como videos con subtítulos, recursos interactivos y aplicaciones que conectan palabras, imágenes y gestos ayudan a crear aprendizajes más significativos [14], [15].
En síntesis, las aplicaciones móviles suelen apoyarse en metodologías ágiles cuando integran software, servicios en la nube y dispositivos físicos, debido a que estas facilitan la organización del trabajo y la incorporación progresiva de módulos funcionales [16], [17], [18]. En ese marco, la presente investigación tuvo como objetivo desarrollar un prototipo móvil capaz de recibir texto o voz en español, traducirlos al quichua mediante IA y mostrar una representación visual de señas ecuatorianas asociadas a las salidas obtenidas. El aporte del estudio se orientó a comprobar la viabilidad técnica de integrar estos componentes en una sola aplicación, más que a demostrar de forma concluyente un impacto educativo o comunicativo en usuarios finales.
El desarrollo del presente trabajo se organizó con el marco ágil Scrum, como se muestra en la Figura 1., utilizado como estrategia de gestión para planificar y construir el prototipo por sprints. Desde el punto de vista funcional, el sistema implementó un flujo compuesto por tres etapas: captura de voz o texto en español, traducción automática al quichua mediante una API y recuperación de la representación visual o robótica disponible en el dataset local. En las primeras iteraciones se configuró el entorno de desarrollo, se creó el proyecto base en Flutter con lenguaje Dart y se definió la arquitectura modular de la aplicación. Posteriormente se implementaron las pantallas principales, el consumo del servicio de traducción y la carga del dataset utilizado para las pruebas.
En las últimas iteraciones se integraron la API de traducción y se realizaron pruebas funcionales hasta lograr un flujo estable desde la entrada de la palabra hasta la ejecución visual de la seña. Los materiales utilizados incluyeron un dispositivo móvil con sistema operativo Android para ejecutar la aplicación, un equipo de cómputo para alojar la API de traducción. La aplicación móvil se desarrolló con Flutter y Dart; la API de traducción se programó en Python utilizando el framework Flask. Para el reconocimiento de voz se empleó Google Speech-to-Text, que permitió obtener texto en español a partir del audio. El diccionario de señas se almacenó en un archivo en formato Excel, donde se registraron palabras en español, su traducción al quichua.
Como parte de la metodología se realizó un análisis exploratorio de cuatro alternativas de traducción automática para el par español-quichua: NLLB-200, GPT, Google Neural Machine Translation y Helsinki-NLP/MarianMT. La comparación se aplicó sobre un conjunto de 13 palabras y expresiones de uso básico presentes en el repertorio implementado del prototipo, seleccionadas por su correspondencia con señas ya registradas en el dataset local. Para cada modelo se ejecutó la traducción de los mismos términos y se registró una valoración comparativa considerando tres aspectos: adecuación semántica de la salida respecto a la forma esperada en el prototipo, estabilidad ante variaciones simples de escritura y facilidad de integración dentro de una API en Python. Los resultados resumidos de esta evaluación se presentan en la Tabla 1. A partir de esta comparación se seleccionó un modelo de la familia NLLB-200, debido a que mostró mayor consistencia en las salidas observadas, menor variación ante cambios simples en la entrada y mejor adaptación al flujo móvil-API implementado.
| MODELO | ADECUACIÓN SEMÁNTICA GENERAL | ESTABILIDAD ANTE VARIACIONES SIMPLES | FACILIDAD DE INTEGRACIÓN EN API PYTHON | OBSERVACIÓN GENERAL |
|---|---|---|---|---|
| NLLB-200 (Meta AI) | Alta | Alta | Alta | Mostró el mejor equilibrio entre cobertura multilingüe, consistencia de salida e integración con el flujo móvil-API implementado. |
| GPT | Media | Media | Media | Permite salidas flexibles mediante instrucciones, pero depende del tipo de prompt, de un servicio externo y de revisión humana para mantener consistencia terminológica. |
| Google Neural Machine Translation | Media | Alta | Alta | Presenta integración sencilla y respuestas estables como servicio externo, aunque con menor adaptación a variantes locales del quichua y riesgo de estructuras influenciadas por el español. |
| Helsinki-NLP/MarianMT | Media | Media | Media | Resulta útil para escenarios específicos u offline, pero su desempeño depende del corpus disponible y suele requerir ajuste adicional para una mejor adaptación regional. |
La validación del componente de traducción se enfocó en el desempeño del modelo NLLB-200 dentro del flujo móvil-API. Para ello se trabajó con el mismo conjunto controlado de 13 términos frecuentes pertenecientes al repertorio implementado, verificando cuatro indicadores funcionales: correspondencia semántica general de la salida en quichua, tiempo de respuesta de la API, continuidad del flujo hasta la recuperación de la imagen o seña asociada y generación de una salida utilizable dentro del prototipo. La revisión semántica fue realizada manualmente por el autor responsable del desarrollo, tomando como referencia la salida esperada definida para cada término y su correspondencia con la lógica funcional del sistema. No se contó con evaluación externa ni con validación formal por hablantes nativos de quichua, lo cual constituye una limitación del estudio. Durante las pruebas funcionales efectuadas con la API implementada, se procesaron correctamente los 13 casos evaluados, con un tiempo promedio de respuesta de 0,55 segundos por consulta y una continuidad operativa del 100% en términos de generación de respuesta dentro del flujo técnico del sistema. Cuando se detectaron traducciones ambiguas o poco coherentes, se aplicaron rutinas de normalización y equivalencias en el diccionario para priorizar la forma esperada dentro del prototipo. Aunque estos resultados permitieron confirmar la viabilidad técnica del sistema, se reconoce como trabajo futuro la incorporación de métricas lingüísticas más robustas y pruebas con usuarios de la comunidad objetivo.
Los resultados corresponden principalmente a la integración funcional del prototipo y a sus pruebas internas. En esta etapa no se evaluó el impacto educativo ni la usabilidad con usuarios finales. El desarrollo del sistema permitió articular en una misma solución móvil la captura de voz, la traducción automática español-quichua y la representación visual o robótica de señas ecuatorianas. El componente robótico operó mediante un brazo controlado por servomotores, alimentado con secuencias angulares almacenadas en el dataset local y activadas desde la aplicación cuando existía una coincidencia con el término procesado. En la Tabla 2 se resumen los componentes principales de hardware y software utilizados.
Como parte del proceso de implementación, los módulos del sistema se desarrollaron de manera gradual. La Tabla 3 resume estas actividades de construcción, que sirvieron de base para las pruebas funcionales posteriores y no deben interpretarse por sí mismas como resultados experimentales. La arquitectura general del sistema, representada en la Figura 2, mostró el recorrido de los datos desde la entrada de voz o texto en la aplicación móvil, pasando por la capa de traducción y el mapeo de señas.
| COMPONENTE SISTEMA | TIPO | TECNOLOGÍA/MODELO | FUNCIÓN DEL SISTEMA |
|---|---|---|---|
| Teléfono móvil Android | Hardware | Smartphone Android | Interfaz de usuario y captura de entrada |
| Aplicación móvil | Software | Flutter + Dart | Navegación, entrada de texto/voz y visualización de resultados |
| Servicio de traducción | Software | Python + Flask + modelo NLLB-200 | Traducción español-quichua mediante API REST |
| Reconocimiento de voz | Servicio | Google Speech-to-Text | Conversión de audio a texto en español |
| Dataset local de señas | Datos | Archivo Excel | Almacenamiento de palabras, imágenes y secuencias angulares |
| Brazo robótico | Hardware | Servomotores controlados desde la app | Ejecución física de la seña cuando existe coincidencia |
Entre las herramientas empleadas destacaron además librerías para reconocimiento de voz, comunicación HTTP y lectura del archivo Excel, utilizadas para enlazar la aplicación móvil con la API de traducción y con el repertorio local de señas.
| SPRINT | MÓDULO PRINCIPAL | FUNCIONALIDADES IMPLEMENTADAS |
|---|---|---|
| Sprint 1 | Configuración del entorno | Creación del proyecto en Flutter, estructura modular, configuración de dependencias y control de versiones. |
| Sprint 2 | Interacción y traducción | Entrada por texto/voz, integración con Google Speech-to-Text, consumo de API Flask para traducción español-quichua. |
| Sprint 3 | Alimentación del dataset | Pantalla de registro de nuevas palabras, sliders para test de los servos. |
| Sprint 4 | Interfaz de usuario | Diseño gráfico y navegación entre módulos: inicio, conexión, traducción, configuración. |
Desde la perspectiva del flujo de información, los datos procesados en el prototipo se organizaron en cuatro tipos principales, que se explica en la Tabla 4 Esta clasificación permitió distinguir claramente las etapas de entrada, procesamiento intermedio y salida final hacia la Lengua de Señas Ecuatoriana, lo que facilitó tanto el diseño de la lógica de la aplicación móvil como la validación funcional del sistema.
| TIPO DE DATO | DESCRIPCIÓN EN EL PROTOTIPO |
|---|---|
| Entrada por texto | Palabras en español ingresadas mediante teclado |
| Entrada por voz | Captura de sonido y conversión a texto en español |
| Salida intermedia | Palabra traducida al quichua |
| Salida final | Seña asociada en LSE (se visualiza en la app) |
En cuanto al repertorio disponible, el sistema trabajó con 33 entradas únicas registradas en el dataset local: 13 palabras de vocabulario básico y 20 letras o combinaciones del alfabeto manual. La selección respondió a criterios prácticos de implementación, priorizando términos con imagen asociada y secuencia angular disponible para el brazo robótico. Este alcance permitió ejecutar pruebas funcionales de manera estable, aunque todavía representa una cobertura léxica limitada. Por ello, el dataset no debe entenderse como un corpus amplio de Lengua de Señas Ecuatoriana, sino como un conjunto inicial de trabajo para validar el comportamiento del prototipo. Estas señas se configuraron a partir de un dataset que asoció cada palabra con una secuencia de valores angulares para los servomotores, lo que permitió reproducir posturas consistentes durante las pruebas funcionales, como se muestra en la Tabla 4.
| PALABRA | VECTOR ÁNGULOS [15] | IMAGENPATH |
|---|---|---|
| Abajo | [15,24,24,142,65,50,52,40,50,70,24,60,90,80,0] | assets/images/abajo.png |
| Arriba | [130,52,40,50,70,24,120,90,100,0,130,52,40,50,70] | assets/images/arriba.png |
| A | [30,30,30,40,120,60,60,50,60,90,75,90,90,100,0] | assets/images/letra.png |
| I | [125,130,90,90,100,90,90,90,90,105,125,90,90,100,0] | Assets/images/letrai.png |
Desde la perspectiva de la experiencia de usuario, la aplicación se estructuró en módulos diferenciados que facilitaron la navegación y el uso del sistema. La Figura 3 muestra la pantalla inicial del prototipo móvil, donde se incluyeron accesos directos a conexión, traducción y configuración, con una disposición visual sencilla orientada a reducir la sobrecarga cognitiva. Esta decisión de diseño coincide con enfoques reportados en estudios previos sobre aplicaciones móviles para apoyo comunicativo en personas con discapacidad auditiva; en esos trabajos se ha señalado que la simplicidad de uso favorece la interacción y la aceptación de la herramienta [19], [20]. En el presente estudio, sin embargo, dichos efectos no fueron medidos de forma experimental, por lo que solo se describe la lógica de diseño adoptada.
La separación explícita de este módulo recuerda la importancia de integrar adecuadamente la capa de hardware en aplicaciones móviles de apoyo a la discapacidad auditiva, tema que también se consideró en propuestas donde la comunicación entre dispositivos y aplicaciones educativas fue determinante para la experiencia final del usuario [7].
El módulo de traducción y consulta de señas, mostrado en la Figura 5, integró la entrada de texto o voz en español y la recuperación de la salida procesada dentro de la aplicación. A diferencia de otras propuestas basadas en Flutter orientadas al aprendizaje mediante videos, cuestionarios o recursos multimedia [21], el presente prototipo se centró en enlazar la traducción automática con una representación visual y, en determinados casos, con la ejecución robótica de la seña. Esta diferencia metodológica constituye una ventaja de integración; sin embargo, el trabajo todavía es más limitado en términos de repertorio, validación con usuarios y evaluación de usabilidad.
El funcionamiento del sistema y la precisión de la traducción se detallan a través de los resultados presentados desde la Figura 6 hasta la Figura 9. Para procesar estas consultas, la aplicación utiliza el modelo de inteligencia artificial NLLB-200, el cual analiza el texto ingresado en español y genera su equivalente en quichua, adaptándolo a los términos utilizados en Ecuador.
En los primeros casos de prueba, que corresponden a las letras 'A' (Figura 6) y 'R' (Figura 7), el sistema muestra cómo se identifica la letra. Este proceso facilita que el usuario aprenda el abecedario de forma visual y directa.
Por otro lado, el funcionamiento del prototipo también se observó en casos más concretos. En la Figura 8 se muestra la palabra "Arriba" (traducida como Hawa) y en la Figura 9 la expresión "Un ratito" (traducida como Ashalla), ejemplos utilizados para ilustrar el comportamiento del flujo implementado. En ambos casos, la interfaz presenta la salida en quichua y la representación visual disponible en el dataset local. Esto permitió comprobar el funcionamiento técnico del prototipo en ejemplos específicos, aunque la comprensión de estas salidas por parte de usuarios finales no fue evaluada en esta etapa.
En la comparación con trabajos relacionados, el prototipo se orientó a un problema distinto al de aplicaciones centradas únicamente en la enseñanza de señas o en la traducción texto-voz [22]. A diferencia de SOMUAPP, orientada a la traducción bidireccional texto-voz [20], el presente trabajo integró en un mismo flujo la entrada por voz o texto en español, la traducción automática al quichua y la visualización o ejecución de una seña asociada. Esta integración añade una dimensión intercultural y tecnológica que puede resultar útil en contextos educativos o demostrativos. Sin embargo, frente a otras propuestas reportadas en la literatura, el sistema todavía presenta un repertorio reducido, no incorpora evaluación con usuarios y depende de un flujo controlado de pruebas, por lo que su aporte debe entenderse como exploratorio y funcional.
Las propuestas basadas en realidad aumentada para la enseñanza de la Lengua de Señas Mexicana han mostrado que la superposición de elementos virtuales sobre el entorno físico facilita el aprendizaje de alfabetos y frases básicas, siempre que las señas presentadas mantengan precisión y claridad [7]. De manera complementaria, las aplicaciones móviles desarrolladas con Flutter para el aprendizaje de lenguaje de señas han demostrado que es posible ofrecer interfaces intuitivas, con módulos de alfabeto, números, tutoriales en video y cuestionarios, obteniendo resultados favorables en términos de accesibilidad y aceptación por parte de los usuarios [20]. El prototipo móvil conservó la estructura modular y las ventajas de Flutter para la interfaz.
Frente a enfoques basados en reconocimiento automático de señas mediante sensores o realidad aumentada [23], el prototipo presentado en esta investigación trabajó en la dirección inversa: recibió entradas en español, generó una salida en quichua y, cuando existía correspondencia en el dataset, recuperó una representación visual o robótica de la seña. Esta decisión simplificó la implementación y permitió demostrar la integración básica de los módulos; sin embargo, también limitó el alcance del sistema, ya que no se evaluó reconocimiento gestual, cobertura amplia de vocabulario ni interacción en escenarios reales de uso. Por ello, más que una solución completa, el prototipo debe entenderse como una base técnica inicial para desarrollos posteriores [23].
Como parte del desarrollo del módulo de traducción se revisaron distintas alternativas de modelos de IA para el par español-quichua, considerando su cobertura multilingüe, la disponibilidad de recursos para lenguas originarias, la facilidad de integración y sus limitaciones conocidas. La Tabla 6 presenta una revisión descriptiva de modelos de inteligencia artificial, que corresponde a un análisis documental de alternativas tecnológicas consideradas durante la fase de diseño. La Tabla 5 presenta de forma resumida las características más relevantes de las opciones consideradas y la justificación de la elección de un modelo multilingüe NLLB-200 como núcleo del servidor de traducción integrado en la aplicación móvil. Esta elección se sustenta en estudios recientes que evalúan la traducción automática neuronal en contextos especializados, donde se confirma su utilidad como herramienta de apoyo, pero se subraya la necesidad crítica de supervisión y post-edición humana para garantizar la precisión y adecuación terminológica [24].
| MODELO | DESCRIPCIÓN | USO EN TRADUCCIÓN ESPAÑOL-QUICHUA |
|---|---|---|
| NLLB-200 (Meta AI) | Modelo de IA de "Arquitectura Universal" diseñado para 200 lenguas con pocos recursos. | Fue el modelo seleccionado para este prototipo por su cobertura multilingüe y por su integración funcional dentro del flujo móvil-API implementado. |
| GPT (ChatGPT) | Modelo de lenguaje grande generativo preentrenado, basado en transformadores para procesamiento de lenguaje natural. | Puede generar respuestas flexibles mediante instrucciones específicas, pero su salida depende del tipo de prompt utilizado y requiere revisión humana por posibles variaciones, generalizaciones o diferencias terminológicas. |
| Google Neural Machine Translation (GNMT) | Motor de traducción basado en redes neuronales profundas con soporte para Quechua sureño. | Es una alternativa accesible para traducciones rápidas, aunque puede generar salidas cercanas a estructuras del español y no siempre conservar variantes locales o matices culturales del quichua, por lo que requiere revisión humana y contextualización. |
| Helsinki-NLP (MarianMT) | Modelos de traducción automática Transformer entrenados con el corpus OPUS. | Puede ser útil para despliegues específicos u offline y para futuros ajustes con diccionarios locales de quichua ecuatoriano; sin embargo, su desempeño depende del corpus disponible y de la adaptación regional del modelo. |
Finalmente, experiencias recientes en aplicaciones móviles para el aprendizaje autónomo de la Lengua de Señas Ecuatoriana han evidenciado que es posible alcanzar niveles aceptables de usabilidad, medidos con instrumentos estandarizados como el System Usability Scale, aunque aún persisten desafíos en el diseño de la interfaz y en la calidad de la retroalimentación ofrecida al usuario [4]. Estos resultados resultaron especialmente relevantes para el presente prototipo, ya que las pruebas realizadas se centraron en la validación técnica del flujo de traducción y de la ejecución robótica, sin incluir todavía una evaluación formal con población sorda u oyente. En consecuencia, se identificó como una línea prioritaria de trabajo futuro la aplicación de instrumentos similares para valorar la usabilidad, la comprensión de las señas ejecutadas y el impacto real del sistema en procesos de inclusión y aprendizaje.
Debe señalarse que la validación semántica se realizó mediante revisión manual interna y no contó con la participación de hablantes nativos de quichua ni con evaluadores externos, por lo que los resultados lingüísticos deben interpretarse como una verificación funcional preliminar.
En síntesis, los resultados mostraron que la integración de traducción automática español-quichua con un dataset local de señas controlado desde una aplicación móvil constituye una base funcional para el desarrollo de tecnologías de apoyo. El dataset empleado tuvo origen local y estuvo conformado por 33 entradas únicas, distribuidas en 13 palabras y 20 letras o combinaciones del alfabeto manual, cada una vinculada con una imagen y una secuencia angular para su posible ejecución robótica. Aunque este repertorio permitió comprobar el funcionamiento técnico del sistema, su tamaño reducido, la ausencia de pruebas de usabilidad con población objetivo y las restricciones mecánicas del dispositivo limitan el alcance de los resultados. En ese sentido, el prototipo debe entenderse como una validación inicial y no como una solución completa de traducción o comunicación asistida [19], [23], [25].
El prototipo móvil desarrollado cumple el objetivo de integrar reconocimiento de voz, traducción automática español–quichua, demostrando la viabilidad técnica de este flujo completo de traducción. Sin embargo, el cumplimiento del objetivo se verificó mediante pruebas funcionales internas y todavía no existe una validación con usuarios finales ni evaluación formal del desempeño lingüístico. El sistema se presenta como una solución híbrida que articula modelos de IA, un diccionario de señas mapeado a valores angulares y una arquitectura modular en Flutter, lo que facilita su mantenimiento y futura ampliación.
El prototipo móvil desarrollado permitió integrar en una sola aplicación la captura de voz o texto en español, la traducción automática al quichua y la recuperación de una representación visual o robótica asociada a un conjunto limitado de señas. En este estudio, la viabilidad técnica se definió a partir del funcionamiento continuo del flujo móvil-API-dataset, la respuesta operativa del sistema en los casos probados y la posibilidad de ejecutar o visualizar la seña cuando existía correspondencia en el repertorio implementado.
No obstante, el trabajo no incluyó métricas cuantitativas de desempeño, validación con hablantes de quichua ni pruebas de usabilidad con usuarios finales, por lo que sus conclusiones deben interpretarse dentro de un alcance preliminar. El principal aporte del estudio es ofrecer una base funcional para futuras investigaciones orientadas a ampliar el vocabulario, fortalecer el tratamiento lingüístico del quichua y evaluar de manera más rigurosa el impacto real del sistema en procesos de accesibilidad, inclusión y aprendizaje.
Este trabajo contó con el apoyo del Centro de Ingeniería de Software de la Universidad Católica de Cuenca, institución a la que los autores expresan su agradecimiento por el respaldo académico brindado durante el desarrollo de la investigación.
La presente investigación se desarrolló con recursos propios de los autores y con apoyo académico e institucional del Centro de Ingeniería de Software de la Universidad Católica de Cuenca. No se recibió financiamiento específico de agencias públicas, comerciales ni de entidades sin fines de lucro para la ejecución de este estudio.
Los autores declaran que no existe ningún conflicto de intereses financiero, institucional, profesional o personal que pudiera haber influido en los resultados o interpretaciones presentadas en este estudio.
Los autores declaran que las herramientas de inteligencia artificial generativa fueron utilizadas únicamente como apoyo para la revisión lingüística, corrección de estilo y mejora de la redacción del manuscrito. La conceptualización del estudio, la definición metodológica, la implementación del prototipo, la recopilación y análisis de la información, la interpretación de resultados y la elaboración de conclusiones fueron realizadas por los autores, quienes asumen plena responsabilidad sobre el contenido científico del artículo.
Los datos que respaldan los resultados de este estudio corresponden al dataset local de señas, a los registros funcionales del prototipo y a los materiales técnicos empleados durante su validación. Estos datos no se encuentran disponibles públicamente en esta etapa; sin embargo, podrán ser solicitados al autor de correspondencia mediante petición razonable y con fines exclusivamente académicos o científicos.
[Johnny Alexander Juca] (50%) contribuyó en conceptualización, metodología, desarrollo del software, investigación, análisis formal, validación, visualización, redacción del borrador original y edición del manuscrito. [Milton Alfredo Campoverde] (50%) contribuyó en conceptualización, metodología, desarrollo del software, investigación, análisis formal, validación, visualización, redacción del borrador original y edición del manuscrito.
© 2026 Edú Alexander Espinoza Alvarado, Jorleny Brigitte Escalante Mendoza, Alex Dumany Luna-Florin y Teddy Hendricks Ochoa Pérez.
Artículo de libre acceso bajo los términos de una
Licencia
Creative Commons Reconocimiento – NoComercial – CompartirIgual 4.0 Internacional.
Se permite, sin restricciones, el uso, distribución, traducción y reproducción del documento,
siempre y
cuando
se realice sin fines comerciales y estén debidamente citados bajo la misma licencia.