El idioma de un modelo no es el idioma de una sociedad.

Un modelo multilingüe no es justo porque su interfaz enumera muchos idiomas. La cobertura lingüística es una cuestión institucional, cultural y de...

El idioma de un modelo no es el idioma de una sociedad.

Dieciséis lenguas son un punto de partida, no un veredicto

El 22 de julio de 2026, la Dirección General de Traducción de la Comisión Europea publicó EU MMLU, un punto de referencia concebido para evaluar los grandes modelos lingüísticos en los contextos lingüísticos y culturales europeos. La publicación fue inusualmente honesta sobre la brecha que trataba de cerrar. Muchos conjuntos de datos de evaluación se crearon en inglés. Un modelo puede obtener buenos resultados en esa lengua y, aun así, rendir mal en francés, húngaro o maltés. El nuevo conjunto de datos comienza con dieciséis lenguas oficiales de la UE, siete áreas temáticas y más de mil preguntas traducidas y revisadas por casi 250 estudiantes de 21 universidades europeas.

La parte más importante de ese anuncio no es la lista de lenguas. Es la frase que la acompaña: el comportamiento de un modelo no puede deducirse de la lengua en la que parece más fluido. Eso debería ser evidente. También es el supuesto que subyace a una cantidad notable de contratación pública, investigación y conversación pública. Seguimos hablando de un modelo lingüístico como si tuviera una sola mente y luego le pedimos que vista distintas lenguas como si fueran abrigos. El abrigo cambia. La mente, las pruebas, los puntos ciegos y el entorno social se tratan como si fueran estables.

No lo son. La lengua es el punto de encuentro entre una persona y una institución. En ella se expresan las condiciones de una prestación, el tono de un recurso, la diferencia entre un consejo y una instrucción, la forma de un chiste, el nombre de un lugar y los supuestos de un formulario. Cuando un sistema gestiona una lengua mejor que otra, no solo produce una frase menos elegante. Puede cambiar quién es comprendido, quién es creído, quién puede impugnar un resultado y quién se rinde antes de encontrar la puerta correcta.

La conclusión práctica es clara. La IA multilingüe no es una función de traducción que se añade después de construir el modelo. Es una cuestión de acceso, pruebas y autoridad. El trabajo europeo en tecnologías lingüísticas, datos lingüísticos y evaluación multilingüe es valioso porque trata el problema como infraestructura. La labor sigue incompleta. Un punto de referencia no es una garantía, y dieciséis lenguas no son toda Europa. Pero la dirección es la correcta: dejar de preguntar si un modelo habla una lengua y empezar a preguntar qué puede hacer con seguridad en esa lengua, para quién, en qué condiciones y con qué pruebas.

La cobertura lingüística solo es creíble cuando las afirmaciones sobre la fuente, el contexto, la revisión y el servicio siguen conectadas.

La lengua es una frontera de acceso

Europa ha convertido el idioma en un hecho institucional, no en una preferencia privada. El artículo 22 de la Carta de los Derechos Fundamentales establece que la Unión respetará la diversidad cultural, religiosa y lingüística. La propia política de tecnología lingüística de la Comisión sitúa esa obligación junto a una advertencia práctica: las tecnologías lingüísticas necesitan un uso imparcial para que los derechos y los principios sobrevivan al contacto con el software. No son compromisos decorativos. Describen el límite que encuentra un sistema público cuando un residente no puede leer un aviso, no puede entender por qué se tomó una decisión o no puede expresar un hecho relevante en el idioma en el que ese hecho existe.

Ese límite es fácil de pasar por alto cuando un equipo mide únicamente si se produjo una traducción. Una frase puede llegar en el idioma solicitado y aun así no servir a la persona que la necesita. La traducción puede aplanar una distinción jurídica, cambiar el nivel de cortesía que indica si un funcionario está pidiendo u ordenando, o usar un término que tiene un significado cotidiano pero también un significado especializado en un servicio concreto. Un reconocedor de voz puede convertir una pronunciación regional en una palabra distinta. Un resumidor puede eliminar el matiz que determina la responsabilidad. La fluidez no nos dice si la transacción permaneció intacta.

Imaginemos un servicio público de información que ofrece la misma explicación sobre los requisitos de elegibilidad en neerlandés, francés y una lengua regional. Las dos primeras vías se han entrenado y probado con material administrativo, cartas de recurso y conversaciones con expertos del dominio. La tercera vía tiene una prosa general excelente, pero ninguna evaluación significativa sobre la terminología propia del servicio. Un panel de control puede mostrar tres indicadores verdes de idioma. Los residentes no reciben tres servicios equivalentes. Un grupo recibe una explicación; otro recibe una aproximación; el tercero recibe una incertidumbre pulida que parece oficial porque lleva el logotipo correcto.

El ejemplo es deliberadamente hipotético. No es una afirmación sobre un municipio o un proveedor concretos. Su propósito es exponer un error de diseño. El soporte lingüístico a menudo se cuenta en la interfaz, mientras que la obligación real se encuentra más abajo en la cadena. El sistema debe saber qué datos respaldan el idioma, qué tareas se evaluaron, quién revisó los errores, cómo pueden corregirlos los usuarios y cuándo la vía debe negarse a responder. Si faltan esos detalles, el selector de idioma es una promesa sin contrato.

El mapa de un modelo no es el mapa de la sociedad

Un modelo aprende de un mapa del idioma que sus datos y su proceso de entrenamiento ponen a su disposición. Una sociedad vive en un mapa mucho más amplio. El mapa del modelo contiene los textos, grabaciones, etiquetas, traducciones y evaluaciones que se admitieron. El mapa de la sociedad contiene personas que hablan de forma distinta en casa y en el trabajo, que cambian de registro sin anunciarlo, que toman prestadas palabras a través de una frontera, que usan una lengua minoritaria en una institución local o que escriben en una escritura que un punto de referencia no incluyó. Un mapa es un artefacto técnico. El otro es una disposición de vidas, derechos y obligaciones.

La diferencia importa incluso para idiomas con grandes corpus públicos. Una lengua nacional no es una corriente uniforme. Los formularios gubernamentales, las decisiones judiciales, el habla en el aula, los consejos de salud, los mensajes de texto y una conversación entre vecinos usan vocabularios distintos y tolerancias distintas ante la ambigüedad. Un modelo puede ser competente en prosa periodística y débil en un recurso de prestaciones. Puede manejar la ortografía estándar y tener dificultades con un dialecto. Puede traducir una frase literal y no captar el significado pragmático que transmite una fórmula cortés. Llamar soportado al idioma completo oculta el límite de la tarea.

La tecnología del lenguaje necesita, por tanto, un vocabulario más preciso. Debemos distinguir entre que una lengua esté presente en los datos de entrenamiento y que una tarea se evalúe en esa lengua. Debemos distinguir entre una traducción de referencia y un elemento de prueba redactado de forma independiente. Debemos distinguir entre leer una escritura y comprender el registro de una comunidad. Debemos distinguir entre la capacidad de un sistema para generar texto y su autoridad para asesorar, clasificar o decidir. Cada distinción es una pequeña pieza de trabajo administrativo. Juntas impiden que una afirmación general se construya a partir de pruebas limitadas.

Hay una razón institucional para ser estrictos. Los servicios públicos no son libres de elegir la lengua más fácil y llamar eficiente al resultado. Un banco, un hospital, un empleador o un proveedor de software pueden tener obligaciones legales distintas, pero cada uno decide cuánta fricción debe absorber una persona para que se la entienda. Una vía multilingüe que falla en silencio transfiere el coste al usuario. El usuario debe buscar un traductor, repetir su historia, aceptar un peor resultado o abandonar el proceso. El sistema informa de éxito porque devolvió una cadena. La persona experimenta exclusión con una gramática impecable.

Qué significa realmente «bajos recursos»

A menudo se trata «bajos recursos» como una propiedad de una lengua, como si algunas lenguas llegaran a la puerta del modelo con menos recursos y debieran disculparse por las molestias. Es más útil tratarlo como una propiedad de una tarea, de un conjunto de datos y de una decisión de gobernanza. Una lengua puede tener material literario considerable pero pocos datos etiquetados para un clasificador médico. Puede tener texto paralelo pero casi ninguna grabación de voz. Puede estar representada en un corpus sin los derechos o los metadatos necesarios para un despliegue concreto. Puede tener datos en una forma estándar mientras las personas afectadas usan una variedad regional.

La política de tecnología del lenguaje de la Comisión Europea lo dice con claridad. Los datos lingüísticos son la base de las herramientas lingüísticas, y la experiencia humana es una parte necesaria del éxito del desarrollo. Un modelo necesita texto o habla, algoritmos, computación y personas que comprendan la lengua y el dominio. La eliminación de cualquiera de esos elementos cambia el sistema. Más computación no puede crear una conversación que falta. Más ejemplos no pueden reparar una etiqueta que confunde dos categorías jurídicas. Un modelo más grande no puede decidir qué fuente considera autorizada una comunidad.

El trabajo con lenguas de bajos recursos no es, por tanto, una invitación a rebajar el estándar. Es una razón para hacer visible el estándar. Si una tarea tiene poco material de evaluación, dígalo. Si una métrica es inestable para un par de lenguas, informe de esa inestabilidad. Si la revisión humana fue reducida, identifique el alcance de la revisión en lugar de presentarla como una garantía general. Si una vía es útil para redactar pero no para tomar decisiones, ponga ese límite donde un comprador y un usuario puedan verlo. La escasez honesta es más segura que un silencio que parece abundante.

El panorama lingüístico de Europa hace inevitable esta disciplina. La Comisión describe un conjunto complejo de lenguas oficiales, regionales y minoritarias y ha apoyado iniciativas como European Language Grid, la agenda European Language Equality y el Espacio Común Europeo de Datos Lingüísticos. Estos proyectos no son una solución única y no deben describirse como tal. Son piezas de un ecosistema en el que pueden encontrarse datos, herramientas, derechos, experiencia e instituciones públicas. La forma institucional es tan importante como el modelo que contiene.

La capa de derechos llega antes que el punto de referencia

Es tentador hablar de los modelos de lenguaje como si el lenguaje fuera un canal de entrada neutro. No lo es. La entrada puede contener datos personales, una característica protegida, un topónimo local, un detalle médico o el registro de una persona que pide ayuda. La fuente puede estar sujeta a derechos de autor o a una reserva. Una salida traducida puede utilizarse en una decisión aunque la ruta de traducción nunca se haya evaluado para ese contexto. El problema lingüístico del modelo ya es un problema de derechos antes de que nadie elija una puntuación.

La orientación de la Comisión sobre tecnología lingüística vincula los datos lingüísticos tanto con los derechos de autor como con la protección de datos. Esa conexión debería cambiar la forma en que los equipos diseñan los flujos de trabajo. Un corpus no es simplemente un montón de frases. Tiene identidad de origen, condiciones de adquisición, estado de licencia o derechos, metadatos de idioma y escritura, señales de calidad, finalidad y reglas de retención. Si un elemento se corrige o se retira, la organización necesita saber qué artefactos derivados se vieron afectados. De lo contrario, un modelo posterior puede repetir un error antiguo con la confianza de un formulario recién impreso.

Aquí es donde la expresión procedencia demuestra su valor. La procedencia no es una nota a pie de página que diga que los datos vinieron de algún lugar. Es el conjunto de relaciones que permite a un revisor pasar de un resultado a la evidencia relevante y volver. En el trabajo multilingüe, esas relaciones deben sobrevivir a la traducción, la transcripción, la normalización, la segmentación y la evaluación. Una frase traducida para un punto de referencia no es intercambiable con la frase original. Una etiqueta creada por un revisor no es intercambiable con una etiqueta heredada de otro idioma. La transformación forma parte de la evidencia.

No hay ningún requisito de que cada usuario vea un registro de investigación. Hay un requisito de que una organización pueda responder a una pregunta seria cuando llegue. ¿Qué versión del recurso lingüístico se utilizó? ¿Qué tarea respaldaba? ¿Qué expertos lingüísticos la revisaron? ¿Qué hizo el sistema cuando la confianza era baja? ¿Se trató una queja como una corrección de una sola respuesta o como una posible clase de fallos? La ruta lingüística se vuelve fiable cuando estas preguntas tienen responsables y registros.

Europa está construyendo infraestructura lingüística, no solo botones de traducción

La descripción de la Comisión Europea del Espacio Común Europeo de Datos Lingüísticos es útil porque no reduce el proyecto a una versión de modelo. El objetivo es una plataforma y un mercado para recopilar, compartir y reutilizar datos lingüísticos multilingües y multimodales, manteniendo al mismo tiempo el control de las organizaciones y las personas que generan los datos. Esa redacción apunta hacia una idea diferente de progreso. El trabajo no consiste solo en producir una mejor frase. Consiste en hacer que los recursos lingüísticos sean descubribles, respetuosos con los derechos, reutilizables y responsables en la administración pública, la investigación y la industria.

La European Language Grid dio un paso similar al incorporar herramientas y recursos de tecnología lingüística especializada a un catálogo común. Un catálogo no demuestra que cada servicio funcione para cada tarea. Sí facilita la inspección de una dependencia oculta. Un equipo puede preguntar qué hace la herramienta, qué idioma admite, de dónde proceden sus datos y si la licencia se ajusta al uso previsto. Es una infraestructura poco llamativa. También es así como un continente con muchas instituciones evita reconstruir la misma capacidad lingüística en salas desconectadas.

La infraestructura importa porque la larga cola del trabajo lingüístico no se resuelve con un único modelo insignia. Un organismo público puede necesitar reconocimiento de voz para un acento regional, extracción de terminología para un dominio especializado, memoria de traducción para la legislación, reconocimiento de entidades nombradas para topónimos, o una forma de comparar dos versiones de un documento sin perder los signos diacríticos. Una empresa puede necesitar un despliegue local porque el material no puede salir de su jurisdicción. Un grupo de investigación puede necesitar un conjunto de datos con una procedencia clara en lugar de otra puntuación anónima.

Hay una elección política silenciosa en este enfoque. Los datos y las herramientas se tratan como capacidades que Europa debería poder inspeccionar y moldear, no como un servicio que llega desde un lugar invisible. Eso no significa que los sistemas europeos sean automáticamente buenos ni que los proveedores comerciales de otros lugares no puedan ser útiles. Significa que un idioma es demasiado importante como para quedarse sin un vocabulario público para sus datos, sus vacíos y su evaluación. La soberanía comienza por saber lo que el sistema no puede ver.

La traducción no es una tubería neutral

La traducción suele colocarse entre dos componentes en un diagrama de arquitectura, como si fuera una tubería que transporta el significado de un lado a otro. La traducción real es una secuencia de decisiones. ¿Qué texto fuente es el autoritativo? ¿Qué palabras deben permanecer exactas? ¿Qué ambigüedad debe conservarse? ¿Qué referencia cultural necesita una explicación? ¿Qué registro es apropiado para un aviso público? ¿Qué entidad no debe traducirse? ¿Qué fecha, número o unidad debe expresarse según la convención del lector? Un modelo puede tomar esas decisiones con rapidez. La rapidez no las hace invisibles.

Considere la diferencia entre traducir una frase meteorológica y traducir un aviso sobre un plazo. En el primer caso, un pequeño error de estilo puede resultar molesto. En el segundo, un número o un verbo modal puede alterar lo que una persona cree que debe hacer. El modelo lingüístico subyacente puede tener el mismo presupuesto de tokens y la misma visualización de confianza. Las consecuencias sociales no son las mismas. La evaluación debe, por tanto, seguir la tarea, no detenerse en una puntuación general de idioma.

La página de la Comisión sobre su propio uso de los idiomas plantea la cuestión sin dramatismo. La traducción automática puede ofrecer una idea básica, pero la calidad y la precisión varían significativamente de un texto a otro y entre pares de idiomas. Es una frase pública útil porque se niega a convertir un servicio en un oráculo. Da al lector permiso para usar una traducción como orientación, al tiempo que conserva una razón para buscar una versión humana o autoritativa cuando la consecuencia lo justifique.

Para los equipos de producto, la implicación es un conjunto de rutas explícitas. Una traducción de bajo riesgo puede devolverse directamente con un estado claro. Una ruta legal o médica puede requerir revisión humana, un enlace a la fuente o una negativa. Un borrador interno puede conservar la fuente junto a la traducción. Una interfaz de voz puede repetir un nombre crítico y pedir confirmación. La elección no es entre automatización total y ninguna automatización. Es entre un proceso que declara sus traspasos y uno que los oculta tras un párrafo fluido.

La frase sobrevive, la situación no

Los modelos trabajan con representaciones. Las sociedades trabajan con situaciones. Cuando una traducción pasa de una a otra, los pequeños detalles pueden convertirse en todo el significado. Una frase que es cortés en un idioma puede sonar evasiva en otro. Un término que distingue un derecho estatutario de un servicio discrecional puede reducirse a una palabra genérica para ayuda. Un modismo puede traducirse literalmente y convertirse en un sinsentido, o traducirse libremente y perder la referencia que identifica a una comunidad. Ninguno de estos fallos necesita una salida absurda. La respuesta peligrosa es la que parece normal.

El lanzamiento de EU MMLU señala exactamente este territorio. Sus criterios de calidad piden que los puntos de referencia multilingües evalúen no solo el significado y la dificultad, sino también los modismos, el humor, las referencias culturales, los formatos de fecha y número, y las diferencias en el tono o la cortesía esperados. Esta es una ampliación importante del objetivo de evaluación. A un modelo lingüístico no se le pregunta solo si puede producir una frase gramatical. Se le pregunta si la frase pertenece a la situación en la que una persona actuará basándose en ella.

La mención del humor no es una invitación a hacer el benchmark entretenido. Reconoce que el humor es una prueba de esfuerzo para el contexto. Una traducción literal puede conservar las palabras y destruir el chiste. Una traducción adaptada culturalmente puede conservar el efecto mientras cambia la referencia. En un servicio público de información, el mismo mecanismo aparece sin risas. Un proverbio, un nombre de lugar local o un saludo formal pueden indicar quién habla y qué relación crea el mensaje.

Cuando los equipos dicen que un modelo entiende un idioma, deberían preguntarse a qué capa se refieren. ¿Reconoce la escritura? ¿Segmenta las palabras correctamente? ¿Identifica entidades? ¿Traduce la proposición? ¿Preserva la fuerza legal? ¿Sigue una convención local? ¿Mantiene el nivel de certeza del hablante? ¿Gestiona una ortografía no estándar? ¿Responde en el registro adecuado? Son capacidades separadas. Una única etiqueta llamada multilingüe oculta el trabajo necesario para establecer cada una de ellas.

Por qué la evaluación debe viajar con el idioma

La evaluación suele añadirse al final porque los equipos quieren un número que asociar a un modelo. Los sistemas multilingües hacen imposible ese orden. Los datos de prueba determinan qué se considera un error. El idioma determina cómo puede fallar una frase. El dominio determina qué fallo importa. El usuario determina si la respuesta del sistema es una ayuda o un obstáculo. La evaluación tiene que viajar con los cuatro.

El artículo de investigación europeo Towards Multilingual LLM Evaluation for European Languages demuestra la escala del problema. Los autores evalúan 40 modelos de lenguaje en 21 idiomas europeos, examinan versiones traducidas de cinco benchmarks muy utilizados y publican un marco que incluye EU20-MMLU, EU20-HellaSwag, EU20-ARC, EU20-TruthfulQA y EU20-GSM8K. El artículo no afirma que traducir un benchmark existente lo haga automáticamente justo. Trata los servicios de traducción, la construcción de benchmarks y la comparabilidad entre idiomas como aspectos que deben investigarse.

Esa es la postura correcta. Un elemento de prueba traducido puede heredar un cambio de dificultad, una suposición cultural o una pista que no existía en el original. Un modelo puede puntuar más alto porque la redacción traducida facilita la respuesta, no porque el modelo se haya vuelto más capaz. Puede puntuar más bajo porque una construcción gramatical resulta poco natural en el idioma de destino, aunque el razonamiento subyacente sea sólido. Ambos resultados son evidencia sobre la prueba y también sobre el modelo.

La revisión humana sigue siendo necesaria, pero también necesita un contrato. ¿Quién revisó el elemento? ¿Los revisores eran hablantes nativos, especialistas del dominio o ambos? ¿Revisaron frases aisladas o la tarea en contexto? ¿Se registraron los desacuerdos? ¿El benchmark conservó respuestas alternativas aceptables? Un experto en idiomas puede decirnos que una frase es incorrecta. Un experto en el dominio puede decirnos por qué la incorrección cambia una decisión. Una evaluación creíble a menudo necesita ambos y debe indicar cuál tuvo.

La cuestión no es hacer que todo sistema supere un examen interminable antes de que nadie pueda usarlo. Es evitar que una prueba limitada se confunda con una afirmación amplia. Si un modelo ha sido evaluado con preguntas fácticas breves en lenguaje escrito estándar, que se informe de eso. No permita que el resultado se convierta silenciosamente en una afirmación sobre la interacción oral, la redacción jurídica, la administración local, los niños, las personas mayores o todos los registros del idioma.

Una puntuación resulta útil cuando se mantienen visibles los límites de su tarea, su idioma, su contexto y su revisión.

La lección del maltés y el euskera

Una ponencia presentada en la conferencia LREC-COLING de 2024 estudió la evaluación de la traducción automática del inglés al maltés y del español al euskera. Los autores examinaron la métrica de evaluación COMET, recopilaron evaluaciones humanas directas y comprobaron cómo se comportaba la métrica al adaptarla a los dos pares de idiomas. Su conclusión es modesta pero relevante: el rendimiento de la métrica puede mejorar con un ajuste fino, y puede ser muy sensible a la distribución de las puntuaciones en sus datos de entrenamiento, especialmente en entornos con pocos recursos.

No es la historia de una métrica que falla. Es la historia de de qué depende una puntuación. Una métrica entrenada con una distribución puede comportarse de forma distinta cuando se le pide que juzgue otra. Un par de idiomas con menos material de evaluación puede hacer que la puntuación parezca más concluyente de lo que es. Un sistema que resulte cómodo de comparar puede seguir siendo un mal sustituto de lo que los hablantes consideran una buena traducción. Los juicios humanos no hacen que la evaluación sea perfecta, pero sacan a la luz los puntos donde una medida automática está haciendo suposiciones.

Otro estudio de 2024, Benchmarking Low-Resource Machine Translation Systems, compara sistemas disponibles públicamente en cuatro conjuntos de datos y 26 idiomas, y publica los resultados a través de BENG, una plataforma FAIR de evaluación comparativa para la generación de lenguaje natural. De nuevo, la aportación no es una clasificación universal. Es una comparación más inspeccionable. La eficiencia y la eficacia se consideran conjuntamente, y la lista de idiomas es visible. El lector puede preguntarse si la evaluación comparativa incluye la ruta que le importa, en lugar de aceptar una única cifra destacada.

Estos estudios ofrecen una lección europea de contención. Lo difícil no es inventar otra puntuación. Es construir una evaluación que permita al lector ver qué idioma, qué tarea y qué definición de calidad han producido la puntuación. Cuando falta ese contexto, un número se convierte en un cruce de frontera sin pasaporte. Puede pasar la presentación, pero nadie puede establecer de dónde ha salido.

La cobertura lingüística puede ser una propiedad de seguridad

Los debates sobre seguridad suelen centrarse en el contenido que un sistema debe rechazar, los ataques que debe resistir o los errores que debe detectar. El idioma añade otra pregunta: ¿puede el sistema reconocer cuándo está fuera de su competencia? Una ruta que funciona en un idioma puede fallar más a menudo en otro manteniendo el mismo tono de confianza. Si la interfaz no expone la diferencia, los usuarios no pueden calibrar su confianza.

Esto es especialmente importante cuando el lenguaje forma parte de una interacción crítica para la seguridad. Un paciente puede describir un síntoma en una variedad regional. Un trabajador puede notificar un peligro con un término local. Un residente puede presentar un recurso con una convención ortográfica que un normalizador trata como ruido. Un modelo puede ser técnicamente preciso en su punto de referencia y operativamente inseguro para esa vía. La pregunta relevante no es si el sistema puede generar una respuesta plausible. Es si los controles de seguridad se evaluaron con el lenguaje y la situación que tiene delante.

La seguridad no exige tratar cada vía lingüística como una emergencia especial. Exige ajustar el control a la consecuencia. Un resultado de búsqueda de bajo riesgo puede mostrar sus fuentes e invitar a una corrección. Una interfaz de clasificación médica puede derivar entradas lingüísticas inciertas a un profesional cualificado. Un flujo de trabajo de documentos legales puede mantener la fuente y la traducción lado a lado y exigir aprobación antes de la publicación. Un sistema de voz puede pedir al usuario que repita un nombre en lugar de seleccionar silenciosamente la entidad familiar más cercana. Son decisiones de ingeniería ordinarias cuando el lenguaje se trata como parte del límite del sistema.

La negativa en sí misma necesita diseño lingüístico. Decirle a un usuario que un sistema no puede responder no es suficiente si la negativa es opaca, condescendiente o no está disponible en el idioma del usuario. El sistema debería decir qué no pudo establecer, qué información ayudaría y qué vía humana o autorizada está disponible. De lo contrario, un control de seguridad se convierte en otra barrera de acceso. El principio lingüístico de Europa se pone a prueba con mayor claridad cuando un sistema no puede proporcionar la respuesta solicitada.

El diseño operativo de un servicio multilingüe

Un servicio multilingüe fiable tiene una forma operativa fácil de describir y sorprendentemente difícil de mantener. Primero, nombra la tarea. La traducción, la transcripción, la clasificación, la recuperación, el resumen y la generación no son intercambiables. Segundo, nombra la vía lingüística, incluida la escritura y cualquier límite regional o de dominio relevante. Tercero, registra el material de origen y las transformaciones aplicadas. Cuarto, define la vía de revisión y escalado. Quinto, informa al usuario de lo que el sistema puede y no puede afirmar.

Esos pasos no son una exigencia de una burocracia gigante. Son el mínimo necesario para que una promesa lingüística sea comprobable. Si un proveedor dice que un modelo es compatible con el finés, un comprador debería poder preguntar si eso significa generación de texto, reconocimiento de voz, traducción desde qué idiomas o todo lo anterior. Si un equipo de producto dice que es compatible con una lengua regional, debería decir si la compatibilidad se basa en datos nativos, datos traducidos, un pequeño conjunto de evaluación o una revisión de expertos. Si la respuesta es desconocida, desconocido es un estado válido.

El servicio también necesita una política de cambios. Nuevo material de formación, un nuevo tokenizador, un nuevo modelo de traducción, una nueva lista de terminología o una nueva población de usuarios pueden cambiar el comportamiento lingüístico. Una versión que mejora una vía puede hacer retroceder otra. Un resultado de referencia del año pasado no describe automáticamente el sistema actual. Los registros de versiones, las pruebas comparativas y una vía para notificar errores específicos del idioma hacen que el servicio sea mantenible en lugar de ceremonial.

El mantenimiento tiene una vertiente humana. Los expertos en idiomas necesitan una forma de ver los errores que afectan a sus comunidades. Los equipos de dominio necesitan una forma de distinguir un error de traducción de una ambigüedad de política. Los operadores necesitan una forma de pausar una vía sin esperar a que un proveedor de modelos interprete una queja. Los usuarios necesitan una forma de decir que el sistema malinterpretó una palabra, un contexto o el nombre de una persona. Un servicio multilingüe no está completo cuando el modelo se despliega. Está lo bastante completo para ser responsable cuando llegue el siguiente problema lingüístico.

Procedencia a través de un canal de procesamiento lingüístico

La procedencia se vuelve concreta cuando seguimos una pieza de significado a través de un sistema. Empecemos con un párrafo de origen. Registremos su idioma, escritura, autor o institución cuando se conozcan, derechos y propósito. Si está segmentado, conservemos la relación con el original. Si está traducido, retengamos la fuente y el traductor o el proceso de traducción. Si un revisor cambia la redacción, registremos eso como un nuevo estado, no como un reemplazo silencioso. Si el párrafo se convierte en un elemento de referencia, llevemos consigo la tarea, la clave de respuestas, el idioma y el registro de revisión.

En tiempo de ejecución, la misma disciplina se aplica a la inversa. Almacenemos qué ruta de idioma gestionó la solicitud, qué versión de modelo o herramienta se ejecutó, qué evidencia de origen se recuperó, qué estado de incertidumbre o rechazo se alcanzó y qué acción humana siguió. El registro no necesita exponer contenido privado a cada operador. Sí necesita poner los hechos materiales a disposición de un revisor autorizado. Sin ellos, un incidente lingüístico se convierte en un debate sobre impresiones.

Aquí es donde la procedencia multilingüe difiere de un registro de auditoría genérico. Una marca de tiempo y un nombre de modelo nos dicen que algo ocurrió. No nos dicen si la fuente se tradujo, si la respuesta cambió un formato numérico, si una entidad nombrada se normalizó o si el revisor trabajaba en el idioma de destino. La ruta de transformación es la evidencia. Una respuesta breve puede ocultar una larga cadena de decisiones.

Hay una pequeña virtud neerlandesa en este enfoque: mantengamos el registro lo bastante aburrido como para que alguien pueda usarlo un martes por la tarde. Un registro de procedencia no debería ser una etiqueta de museo escrita para una auditoría que quizá nunca llegue. Debería ayudar a un operador a responder la siguiente pregunta, detener la ruta correcta y explicar el resultado a una persona a la que no le interesa el diagrama de tu arquitectura. Una buena gobernanza lingüística es ligeramente monótona. Así es como sabes que podría sobrevivir al contacto con el trabajo.

Las decisiones ocultas en una traducción

Todo sistema de traducción conlleva decisiones que merecen un nombre. La tokenización decide cómo se divide la entrada. La normalización decide qué distinciones se conservan o se descartan. La alineación decide qué partes de dos textos se tratan como equivalentes. La terminología decide qué palabras son estables. La decodificación decide cómo se selecciona la salida. El postprocesado decide lo que ve el lector. Ninguno de estos pasos es inherentemente incorrecto. Cada uno puede crear un fallo específico del idioma que es invisible en una demostración general.

Tomemos un nombre propio. Un sistema puede traducirlo, transliterarlo, conservarlo o sustituirlo por una grafía conocida. Para un poema, varias opciones pueden ser defendibles. Para un documento de identidad, solo una puede ser aceptable, y esa puede depender de la autoridad emisora. Tomemos una unidad o una fecha. Los valores pueden seguir siendo matemáticamente equivalentes mientras la forma se vuelve ambigua para el lector. Tomemos un sustantivo o pronombre con género. Una traducción puede introducir información que la fuente omitió, o borrar una distinción que la fuente hizo deliberadamente.

La respuesta de diseño no es congelar el idioma. Es declarar la política y hacer visible la excepción. Una lista de terminología puede proteger términos legales. Una regla de entidades nombradas puede evitar que una ciudad se convierta en una persona. Una vista que conserva la fuente puede permitir al revisor comparar el original y la salida. Una escalada humana puede activarse por un nombre de baja confianza, un desacuerdo entre rutas o una tarea clasificada de alto impacto. El modelo sigue siendo útil porque sus límites forman parte del flujo de trabajo.

Los modelos de lenguaje extensos hacen que las decisiones sean más difíciles de ver porque la salida es fluida. La salida fluida es una interfaz maravillosa y una explicación poco fiable. El sistema puede producir una frase que suene nativa mientras selecciona el sentido incorrecto de una palabra. Puede conservar el tema general mientras omite una negación. Puede traducir una expresión local a una fórmula estándar que cambia la postura del hablante. Por eso la calidad del lenguaje no puede representarse solo con la gramática. El significado tiene una forma social.

Alfabetos, dialectos, registros e instituciones

A menudo se anuncia el soporte lingüístico al nivel del nombre de un idioma, pero los lectores se encuentran con alfabetos, variedades y registros. Un sistema que maneja la ortografía estándar moderna puede tener dificultades con documentos históricos. Un reconocedor de voz puede manejar audio de estudio y fallar en una estación abarrotada. Un chatbot de atención al público puede responder en un registro formal mientras que el usuario necesita un lenguaje sencillo. Una institución puede usar un término que difiere del habla ordinaria por una razón que es jurídicamente importante.

Estos no son casos extremos en el sentido despectivo. Son los lugares donde el lenguaje se encuentra con el mundo. Un nombre regional puede marcar la diferencia entre una dirección correcta y una entrega fallida. Una palabra dialectal puede ser la única palabra que una persona conoce para un síntoma. Una frase formal puede indicar que un mensaje tiene efecto jurídico. Una variante de alfabeto puede determinar si un documento es buscable. Si un punto de referencia excluye estas rutas, puede seguir siendo útil, pero no puede sustituir a la lengua en su conjunto.

Probar todas las variedades no siempre es posible. La respuesta honesta es describir el subconjunto compatible e invitar a aportar evidencia sobre el resto. Un sistema puede publicar que fue evaluado en neerlandés escrito estándar para el resumen de información pública, sin hacer afirmaciones sobre el reconocimiento del habla regional. Puede añadir una prueba para el frisón o el euskera sin pretender que esa adición resuelve todas las cuestiones de las lenguas regionales y minoritarias. La especificidad no es una debilidad. Indica a los usuarios dónde está el límite.

Las instituciones también deberían resistirse a la idea de que una ruta lingüística nacional única es automáticamente neutral. El lenguaje administrativo puede ser inaccesible para hablantes de la misma lengua. La accesibilidad y el multilingüismo se solapan porque ambas preguntan si el lector puede comprender y actuar. El trabajo lingüístico de la Comisión incluye herramientas de simplificación y textos accesibles precisamente por esta razón. Una frase puede ser lingüísticamente correcta y, aun así, ser institucionalmente inutilizable.

Cuando la interfaz es fluida pero incorrecta

Los fallos lingüísticos más difíciles no son espectaculares. Son respuestas que pasan la prueba de la vista. Un resumen incluye los nombres correctos pero cambia quién es el responsable. Una traducción conserva los sustantivos pero convierte una recomendación en una instrucción. Un clasificador entiende el tema pero pasa por alto una negación. Un sistema de voz reconoce las palabras pero no la vacilación del hablante. Un usuario lee la salida en su propia lengua y da por sentado que la fluidez es señal de cuidado.

Deberíamos diseñar para esta clase de error en lugar de esperar a que un ejemplo extraño se convierta en titular. Compare la fuente y la salida en los contenidos de alto impacto. Conserve los marcadores de incertidumbre. Mantenga las citas o las referencias documentales adjuntas. Pida confirmación cuando un número, un nombre o una fecha límite sean centrales. Haga que la ruta sea visible para el operador. Ofrezca un mecanismo de corrección que no exija al usuario saber qué componente falló. Estos controles son pequeños, pero convierten una traducción en una transacción inspeccionable.

La revisión humana no debe describirse como una línea final mágica. Los revisores tienen límites de tiempo, carencias en su ámbito de especialización y sus propios supuestos lingüísticos. Una interfaz de revisión útil les ofrece la fuente, el resultado, el contexto y el motivo de la escalada. Registra el desacuerdo en lugar de suavizarlo. Si los revisores corrigen un término repetidamente, la organización puede mejorar la terminología o cambiar el límite de la tarea. Si el desacuerdo revela que la propia fuente es ambigua, la acción correcta puede ser preguntar al autor, no entrenar más al modelo.

Los operadores también necesitan una forma de ver las pruebas negativas. ¿Qué lenguas no se evaluaron? ¿Qué tareas no tienen revisión humana? ¿Qué solicitudes se rechazaron? ¿Qué usuarios abandonaron la ruta después de una traducción? Una ausencia puede ser una señal. Un gráfico de cobertura en verde que omite las rutas fallidas es un mapa de la superficie comercial, no del servicio.

La experiencia humana no es un botón de respaldo

La política europea de tecnología lingüística sitúa a lingüistas, científicos de datos, ingenieros informáticos y especialistas de dominio en la misma frase. Eso es un requisito de diseño, no una lista de profesiones a las que invitar a una reunión de lanzamiento. Cada persona ve un fallo distinto. El lingüista ve una construcción poco natural o una distinción perdida. El ingeniero ve un problema de segmentación o de enrutamiento. El especialista de dominio ve un error de categoría peligroso. El operador ve una cola que nadie puede asumir. La persona que usa el servicio experimenta una decisión que ya no tiene sentido.

La experiencia humana debe intervenir antes de que se congele el punto de referencia. Un experto en lengua puede ayudar a seleccionar material de prueba que represente registros reales y no solo frases limpias. Un experto de dominio puede identificar términos que no deben desviarse. Un representante de la comunidad puede decirle a un equipo qué redacción resulta oficial, familiar u ofensiva. Un responsable de datos puede explicar qué procedencia está disponible y cuál no. Estas aportaciones configuran el contrato del sistema. No son un adorno después de que se hayan tomado las decisiones técnicas.

Hay un coste, por supuesto. Una buena revisión lleva tiempo y paga a personas por un conocimiento que a menudo se trata como invisible. Ese coste forma parte del soporte lingüístico. La alternativa es externalizarlo a los usuarios, que pagan con confusión y apelaciones, o al personal, que traduce y repara la ruta de manera informal. Un sistema que parece barato porque ignora la experiencia lingüística no es eficiente. Simplemente ha trasladado la factura.

Lo que un punto de referencia justo debe exponer

Un punto de referencia multilingüe debe comenzar con una afirmación lo bastante acotada como para poder probarla. La afirmación podría ser que un sistema puede responder preguntas de información pública en un conjunto de lenguas, conservar fechas y números, y negarse cuando falta la evidencia de la fuente. Podría ser que una ruta de traducción gestione un par y un dominio concretos con un nivel de calidad definido. Podría ser que un reconocedor de voz pueda transcribir una variedad especificada en unas condiciones acústicas determinadas. El punto de referencia es un contrato para esa afirmación.

El contrato necesita algo más que una lista de lenguas. Debe exponer la tarea, la fuente, el dominio, el registro, la escritura, la dirección, la longitud del contexto, las condiciones de entrada, las respuestas de referencia, las variantes aceptables, las métricas, la revisión humana y la incertidumbre. Debe indicar si los elementos se redactaron originalmente en cada lengua o se tradujeron. Debe registrar quién los revisó y qué desacuerdos quedaron. Debe separar los resultados agregados de los resultados por lengua. Debe mostrar suficientes ejemplos para que el lector pueda entender qué mide la puntuación.

Los criterios MMLU de la UE son útiles porque amplían el significado de la palabra «justo». La representación equilibrada de las lenguas oficiales de la UE es una parte. Mantener el significado, la dificultad y el valor de la prueba entre lenguas es otra. Probar los valores y los contextos culturales de la UE, incluidos modismos, humor, referencias, formatos de fecha y número, tono y cortesía, convierte el punto de referencia en un instrumento social además de técnico. Los criterios no eliminan el juicio. Hacen que el juicio sea inspeccionable.

Quienes diseñan puntos de referencia deberían publicar segmentos de fallos, no solo promedios. Un modelo puede tener una buena puntuación media y aun así fallar en todos los elementos que impliquen un registro o un tipo de número concreto. Una ruta puede ser eficiente en una dirección y lenta o cara en otra. Una métrica puede correlacionarse con el juicio humano en una lengua y volverse inestable en otra. Las vistas por lengua y por tarea no son un lujo. Son la forma en que un comprador evita adquirir el promedio mientras despliega la excepción.

Por último, un punto de referencia debería declarar lo que no puede decirnos. Una prueba escrita no establece el rendimiento del habla. Una puntuación de traducción no establece la fiabilidad jurídica. Un conjunto de lenguas oficiales no establece el apoyo a las lenguas regionales o minoritarias. Una puntuación alta no establece que una persona pueda impugnar una decisión. La limitación no es una vergüenza. Es el borde del mapa, y los usuarios necesitan verlo antes de zarpar.

Una puntuación es una leyenda de mapa, no el territorio

Los números son útiles porque obligan a una comparación. Son peligrosos porque invitan a una conclusión mayor que la medición. Una puntuación puede decirnos cómo se comportó un sistema en una muestra definida bajo un método definido. No puede decirnos cómo experimentará una comunidad el sistema sin un puente de suposiciones. El puente puede ser sólido. Debe nombrarse.

Supongamos que un sistema mejora en un punto de referencia multilingüe tras el ajuste fino. Eso es evidencia de un mejor rendimiento en esa evaluación. No es automáticamente evidencia de que el sistema sea más seguro en un servicio público. El servicio puede usar terminología diferente, contexto más largo, entrada de voz, un registro distinto o un flujo de trabajo posterior que convierta una sugerencia en una decisión. El punto de referencia puede seguir siendo valioso. Se vuelve más valioso cuando la organización dice qué parte del servicio representa.

La misma disciplina se aplica a la energía, la velocidad y el coste. Una ruta en una lengua con pocos recursos puede requerir más revisión humana o un contexto de recuperación más amplio. Eso no es un defecto que ocultar en un promedio. Es una propiedad del servicio que debería informar el diseño. Las instituciones europeas han dedicado décadas a construir servicios de traducción y lengua porque el coste práctico de la diversidad lingüística es real. Un sistema de IA no elimina ese coste emitiendo texto rápidamente.

No hay vergüenza en elegir una ruta más estrecha. Un equipo puede apoyar bien menos tareas, publicar el límite y añadir lenguas a medida que crece la evidencia. Eso es mejor que reclamar todas las lenguas y pedir a los usuarios que descubran las lagunas. El instinto europeo por un estándar es más fuerte cuando se combina con el instinto neerlandés de comprobar si la cosa funciona un miércoles corriente.

Construir para 24, probar más allá de 24

La Unión Europea tiene 24 lenguas oficiales y de trabajo, y el servicio de traducción de la Comisión opera entre ellas. Ese número crea una base útil para la infraestructura pública. No define la vida lingüística de Europa. Las lenguas regionales, minoritarias, no territoriales y migratorias también configuran comunidades e instituciones. Un sistema construido para 24 puede seguir excluyendo a personas que no usan una de esas rutas, o que usan una lengua oficial en una forma que el sistema no evaluó.

Construir para 24 es, por tanto, una responsabilidad de hacer que la base sea real, no un permiso para detenerse. Una ruta lingüística debe sustentarse con su propia evidencia. Un organismo público debería poder indicar qué lenguas oficiales están cubiertas para qué tareas, qué revisión humana existe y dónde pueden obtener los usuarios una versión autorizada. También debería tener una forma de aprender de lenguas fuera del conjunto inicial sin convertir a la comunidad en un laboratorio de pruebas no remunerado.

Probar más allá de 24 significa algo más que añadir una lengua novedosa a una demostración. Implica trabajar con hablantes, instituciones e investigadores para decidir cuál es la tarea, para qué puede utilizarse el material de origen y qué se considera un error perjudicial. El proceso puede producir una capacidad pequeña y cuidadosamente delimitada. Eso sigue siendo un avance. Una ruta modesta con un contrato claro puede ser más valiosa que una afirmación impresionante que ningún operador pueda defender.

Qué intentamos hacer explícito

En Dweve, abordamos este tema desde el lado de la infraestructura. Loom se describe en nuestro material público de producto como un modelo cognitivo compilado por tareas cuyos componentes lingüísticos generan un grafo de resultados gobernado, mientras que el aprendizaje de restricciones, la composición de grafos, los solucionadores y la verificación ostentan la autoridad de decisión. Esa es una posición arquitectónica, no una afirmación de rendimiento multilingüe. No hace que una ruta lingüística sea correcta. Pero sí dificulta ocultar una obligación: la salida lingüística no debería ser el único lugar donde existan el razonamiento y la evidencia del sistema.

Nuestro trabajo en Ground Truth plantea el mismo punto a una escala más humana. Las personas necesitan suficiente lenguaje compartido para distinguir un modelo de un flujo de trabajo, una predicción de una evidencia y una respuesta fluida de un resultado verificado. En los sistemas multilingües, ese vocabulario necesita una palabra más: ruta. Una respuesta en neerlandés, una en francés y una en euskera no son meras representaciones de un mismo evento interno si la evidencia, la terminología, la revisión y el comportamiento ante fallos difieren. La ruta forma parte de la afirmación.

Esa posición es deliberadamente menos emocionante que decir que un solo modelo entiende Europa. También es más útil. Queremos que un sistema muestre qué recibió, qué fuentes y restricciones pudo utilizar, qué no pudo establecer y cuándo debe intervenir una persona. La lengua es una superficie a través de la cual una persona se encuentra con ese trabajo. La superficie debe ser clara, pero no se le debe permitir borrar la estructura subyacente.

No estamos exentos de los estándares descritos aquí. Un campo de procedencia no repara la falta de datos. Una ruta determinista no demuestra que una traducción sea justa. Una frontera de procesamiento europea no confiere competencia lingüística. La única forma honesta de hacer una afirmación multilingüe es seguir probando, publicar los límites y permitir que los expertos en lenguas cuestionen la ruta. El nombre del producto no es evidencia. El registro lo es.

Un estándar práctico para los equipos

Los equipos que decidan si introducir una función de IA multilingüe pueden empezar con una breve serie de preguntas. ¿Qué debe hacer exactamente el sistema en cada lengua? ¿A qué personas afecta si se equivoca? ¿Qué material de origen es autoritativo? ¿Cómo se crearon los elementos de prueba y quién los creó? ¿Qué registros, escrituras, dialectos y dominios están dentro de la afirmación? ¿Qué hace el sistema cuando no puede establecer el significado? ¿Quién puede pausar la ruta? ¿Cómo puede un usuario corregir una respuesta sin convertirse en el lingüista no remunerado del proyecto?

Las preguntas se vuelven concretas cuando se vinculan a artefactos. Mantenga una ficha de ruta lingüística con la tarea, las variedades lingüísticas admitidas, las familias de fuentes, el estado de los derechos, las versiones del modelo y las herramientas, los resultados de la evaluación, los modos de fallo conocidos y el responsable de la revisión. Conserve ejemplos de errores con su contexto, no solo una puntuación. Mantenga la fuente junto a una traducción de alto riesgo. Conserve un motivo de escalado que un operador pueda entender. Mantenga un registro de cambios cuando cambie un tokenizador, una lista de terminología, un punto de referencia o un modelo.

Los equipos de compras pueden pedir a los proveedores resultados por idioma y por tarea en lugar de una única media multilingüe. Pueden preguntar si un benchmark fue traducido o redactado de forma nativa, si hay juicios humanos disponibles, cómo se gestionan las rutas con pocos recursos y si el proveedor puede exportar las pruebas necesarias para una revisión. Pueden preguntar qué ocurre cuando un idioma no está soportado, porque una negativa y una alternativa silenciosa tienen consecuencias muy diferentes.

Los equipos de producto pueden diseñar la interfaz para mostrar la ruta y la confianza sin dar a entender que un número de confianza es una probabilidad de verdad. Pueden conservar los enlaces a las fuentes, usar un lenguaje claro en las negativas y hacer visibles las acciones de revisión. Pueden evitar la expresión soporta todos los idiomas a menos que puedan definir el verbo. Soporta puede significar mostrar texto, aceptar entradas, traducir, resumir, responder, clasificar, hablar o gestionar un flujo de trabajo regulado. Un selector de idiomas no es una especificación.

Los equipos de investigación pueden publicar conjuntos de datos con procedencia y rutas de corrección. Pueden incluir resultados negativos e informar cuando una métrica no se traslada bien. Pueden invitar a las comunidades lingüísticas a la evaluación antes de que un modelo se declare listo, y pagar por esa experiencia. Pueden resistir la presión de convertir un resultado limitado en una afirmación universal. El benchmark más valioso puede ser el que hace que un equipo elimine una frase de la página de su producto.

La sociedad detrás del modelo

Un modelo de lenguaje puede ser muy bueno produciendo lenguaje sin saber qué hace el lenguaje en una sociedad. Puede predecir una frase, traducir un párrafo y responder a una pregunta mientras pasa por alto la relación institucional que transmiten las palabras. Esa brecha no es prueba de que el modelo sea inútil. Es prueba de que el lenguaje es más que un tipo de dato.

La respuesta de Europa no debería ser una competición por contar idiomas en una ficha de modelo. Debería ser un esfuerzo sostenido para que los datos lingüísticos, los derechos, la experiencia, la evaluación y el control público formen parte de la misma infraestructura. El trabajo de tecnología lingüística de la Comisión, el Language Data Space, la European Language Grid y el benchmark EU MMLU apuntan todos en esa dirección. Los investigadores europeos están probando qué ocurre cuando los benchmarks traducidos se tratan como preguntas de investigación en lugar de instrumentos incuestionables. Este trabajo merece atención porque hace visible técnicamente un viejo hecho político: las personas no viven la Unión en un solo idioma.

La próxima vez que un proveedor diga que un modelo es multilingüe, pregunte qué contiene esa afirmación. ¿Qué idiomas? ¿Qué tareas? ¿Qué comunidades? ¿Qué fuentes? ¿Qué revisión? ¿Qué negativa? ¿Qué registro de cambios? La pregunta no es hostil. Es el comienzo ordinario de la rendición de cuentas.

Una sociedad no se vuelve justa porque una máquina pueda repetir sus palabras. Se vuelve más justa cuando las personas pueden entrar en sus instituciones, entender lo que ocurre, cuestionar un resultado y ser escuchadas en el idioma que acompaña su vida. Un modelo puede ayudar en ese trabajo. No puede definirlo. El idioma de un modelo es una capacidad técnica. El idioma de una sociedad es una responsabilidad compartida.

Fuentes