Publicar con IA en cinco idiomas: qué se rompe de verdad y cómo lo pillas antes que el lector

Publicar en cinco idiomas cuesta hoy lo mismo que publicar en uno. La transcreación con IA — copy readaptado para cada mercado, no traducción literal — ha retirado la barrera económica que mantenía a las pymes dentro de su frontera lingüística. Este sitio lo hace desde hace meses: cada artículo de /risorse sale a la vez en italiano, inglés, francés, español y neerlandés, generado por una pipeline de IA. Los 31 publicados antes de este están todos ahí, en cinco versiones cada uno.

Así que podemos escribir algo que casi nadie escribe: este es el registro de defectos. No hipótesis — las cosas que se rompieron de verdad, cómo las encontramos y qué cambiamos. Cinco clases, y la quinta es la que ningún revisor habría visto jamás, porque el texto era perfecto.

Cinco cosas que se rompieron, y cómo las encontramos

El rasgo común, antes de los detalles: ninguna se interceptó antes de la publicación. Todas salieron después, artículo a artículo, sin muestreo y sin una base terminológica bloqueada sobre los términos legales. Es el hueco de proceso que llena el resto de este artículo.

1. El verbo que convierte un hecho en una acusación

Una frase italiana neutra sobre un caso judicial real, con nombre y partes, llegó al francés con una elección verbal intensificada, editorializante: el sentido se deslizó de constatación a algo muy cercano a una acusación. Ningún error de lengua, ninguna frase mal construida — una deriva de registro en una materia en la que el registro es la sustancia.

Es además la clase más voluminosa que hemos observado: ese mismo artículo exigió tres correcciones de transcreación solo en francés, y otro sobre el sector de la construcción exigió cuatro en neerlandés. La combinación que las produce es siempre la misma — materia legal o regulatoria más traducción adaptativa: la transcreación hace que el texto suene natural en la lengua de llegada, y «natural», en una frase que describe un litigio, a menudo significa «más tajante».

2. El error idéntico en los cinco idiomas

Un artículo describía las prohibiciones del EU AI Act como aplicables solo al sector público. Es incorrecto — y como el error estaba aguas arriba del paso por idioma, en la premisa compartida, la transcreación lo propagó fielmente: mal de forma idéntica en cinco idiomas, en el mismo momento. El perímetro correcto de las prohibiciones está en el artículo dedicado a qué cambia (y qué no) con el EU AI Act para las pymes.

No es una clase lingüística, y justo por eso merece su propia línea: el QA tiene que verificar la afirmación, no la traducción de la afirmación. Cinco revisores nativos te devuelven cinco «se corresponde», y la premisa sigue siendo falsa en las cinco. La redundancia lingüística no es redundancia factual.

3. Las fechas que ningún idioma escribe realmente así

Las datelines no salían en el formato que cada idioma usa de verdad: el orden día/mes, los separadores y las convenciones sobre los nombres de los meses cambian entre los cinco. Es un defecto mecánico, no lingüístico, pero viaja por la misma pipeline y se ve tanto como una mistranslation: un lector neerlandés que ve una fecha escrita a la italiana no piensa «bug de formato», piensa que el sitio no es realmente suyo.

4. Ninguna señal de que el texto se había corregido — este está cerrado

Ninguno de los defectos anteriores llevaba consigo un marcador de revisión visible para el lector: quien había leído la versión equivocada no tenía forma alguna de saber que entretanto se había arreglado. Este punto ya está resuelto y en producción: los artículos corregidos muestran una fecha de revisión visible. Es el único punto de esta lista que es una mitigación completada en vez de una carencia abierta, y también el más barato de copiar.

5. La copia es correcta, es el código el que se equivoca

Esta es la mejor, y es la única clase en la que el texto es correcto y el defecto está en el código. Dos componentes de la home destacaban gráficamente el acrónimo del título mediante una sustitución literal: buscaban la cadena «AI» y la envolvían en un span para acentuarla. La transcreación había hecho su trabajo bien — el francés y el español dicen correctamente «IA» — así que la búsqueda no encontraba nada, no sustituía nada, y los dos idiomas renderizaban un título plano.

Lo importante es cómo falla: en silencio, y en un silencio que se escapa de todos los controles existentes. Ningún error. Ninguna clave de traducción ausente — así que un test de simetría de claves pasa, porque no falta ninguna clave: lo que difiere es el renderizado. Y ninguna relectura lo encuentra, porque el texto es correcto. Se quedó en producción hasta que un trabajo de diseño tocó esa línea por otros motivos. La corrección es trivial: un match de palabra completa sobre la unión de las formas locales — la expresión regular que reconoce tanto AI como IA como palabras autónomas, aplicada al título ya escapado. Pero la lección no es esa.

La lección de verdad: cuando arreglas un patrón, busca el patrón — no el archivo

Los dos componentes eran idénticos en el defecto. El primero se corrigió un ciclo entero antes de que el segundo se llegara siquiera a notar: el arreglo se aplicó donde se había encontrado el bug, no allá donde el patrón vivía. Resultado: un defecto idéntico, vivo, en dos idiomas, superviviente de una vuelta de más sin ningún motivo. Un grep de treinta segundos sobre la sustitución literal los habría cerrado los dos de una vez.

Vale mucho más allá de este caso. Cualquier token que una vista busque literalmente y que cambie de forma de un idioma a otro es candidato al mismo fallo silencioso: acrónimos (AI/IA/KI), la puntuación invertida del español, símbolos de moneda, tratamientos. Si tu código compara una cadena en el idioma de origen, esa comparación es falsa en al menos uno de los idiomas en los que publicas — y no te lo va a decir nadie.

La regla que sacamos de aquí, y que aplicamos: un defecto de patrón no se cierra sobre el archivo, se cierra sobre el repositorio. Antes de la corrección, el grep. Siempre.

MQM: la taxonomía que convierte «revísalo» en una checklist

La industria de la localización ya tiene un nombre para cada una de estas cosas, y tenerlo cambia la forma de trabajar. MQM (Multidimensional Quality Metrics) es la taxonomía estándar de los errores de traducción, mantenida por el organismo que cuida del framework: organiza los defectos en siete dimensiones — Exactitud, Fluidez, Terminología, Estilo, Convenciones locales, Veracidad, Diseño — cada una en tres niveles de gravedad (menor, mayor, crítico), según los modelos de puntuación publicados por el framework. Es la estructura que hay debajo de las normas ISO 5060:2024 (evaluación de la calidad de la traducción) e ISO 11669:2024 (proyectos de traducción), y una guía divulgativa de un proveedor de servicios lingüísticos recorre el armazón completo.

Nuestro registro se mapea encima con una fidelidad casi vergonzosa. El caso francés es Exactitud/Mistranslation, de gravedad alta porque el sujeto era un caso real con nombre. El error de perímetro sobre el AI Act es un defecto de Veracidad — la categoría que existe precisamente para las afirmaciones falsas sobre el mundo — que pasa a ser además de Exactitud una vez transcreado. Las fechas son Convenciones locales. El título sin el realce gráfico es Diseño. Este mapeo, y lo decimos una sola vez, es nuestra lectura de nuestros defectos — no un resultado publicado por nadie.

¿Por qué importa ponerle nombre? Porque una checklist se construye sobre las categorías, no sobre las buenas intenciones. «Que alguien lo revise» no es un proceso: no tiene criterios de salida, no produce un dato, no le dice a quien revisa qué tiene que buscar. «Verifica las siete dimensiones en los tres niveles de gravedad, y registra lo que encuentres» sí.

Back-translation: no es la traducción de ida y vuelta

Una confusión extendida que conviene cerrar ya, porque produce falsa seguridad. La round-trip translation — volver a meter el texto traducido en la máquina para devolverlo al italiano y ver si «vuelve» — es una prueba de humo sobre la calidad del modelo, no un método de QA. La back-translation es otra cosa: un lingüista independiente, que nunca ha visto el original, retraduce el texto localizado hacia la lengua de partida, y el cliente compara las dos versiones buscando las desviaciones de significado. La distinción es definitoria: la guía operativa de un proveedor de localización se construye sobre este punto, y la entrada de glosario de un gran grupo de servicios lingüísticos la define igual.

Es el estándar señalado para los contenidos regulados — contratos, textos legales, material relevante para la seguridad: exactamente la categoría de nuestros dos peores casos. Y funciona donde la relectura falla por una razón mecánica: verifica la equivalencia conceptual, no la fluidez. El verbo intensificado del caso francés era fluidísimo; lo que se había movido era el concepto, y en una columna al lado del original un desplazamiento así se ve a simple vista.

Glosario de tres niveles, aplicado antes del revisor

El control que deberíamos haber tenido el primero es el más aburrido: una base terminológica bloqueada. Las buenas prácticas para contenidos regulados la articulan en tres niveles, descritos por el blog de una plataforma de localización:

• términos de marca y de producto — los nombres que no se traducen nunca, en ningún idioma;
• términos técnicos y de dominio, incluida la terminología normativa y legal, fijada idioma por idioma para que el modelo no pueda inventarse un equivalente plausible pero equivocado;
• términos prohibidos o de riesgo — denominaciones superadas, marcas de terceros, formulaciones jurídicamente resbaladizas.

El detalle que marca la diferencia, sin embargo, está en el orden de ejecución. El glosario debe ejecutarse como control sobre cada segmento antes o durante la transcreación, con las infracciones señaladas antes de que el texto llegue a un revisor: es el flujo que describe la guía 2026 al workflow de enforcement terminológico de un proveedor del sector, que añade además la parte que casi todo el mundo se salta: una base terminológica necesita un propietario con nombre y apellidos y un calendario de revisión, porque un glosario correcto en el lanzamiento se degrada solo con el tiempo. Sobre nuestras dos peores clases, una lista de formulaciones prohibidas — verbos que imputan conductas, afirmaciones de perímetro del tipo «se aplica solo al sector X» — las habría interceptado a las dos antes de la publicación.

La muestra del 10%, ponderada por riesgo en vez de plana

La práctica corriente de los operadores de localización no es revisarlo todo: se muestrea en torno al 10% del volumen entregado para una revisión nativa a posteriori, como describe la guía de localization QA de un proveedor de testing. La parte que de verdad cuenta es la segunda: ese 10% es una base, no una regla, y en los contenidos de alto riesgo — legal, regulatorio, seguridad — hay que subirlo hasta la revisión integral.

Los programas de LQA maduros estructuran niveles de QA distintos — control por muestreo, revisión estándar, revisión completa en contexto — asociados a la tolerancia al riesgo de cada tipo de contenido: es el planteamiento de una guía práctica de language quality assurance de un proveedor de servicios de localización. De ahí la consecuencia incómoda: un porcentaje de muestreo uniforme para todos los temas es ya en sí mismo un defecto de diseño.

Formatos locales y pseudolocalización: la clase que se automatiza

Fechas, números y monedas aparecen señalados con insistencia como la clase de bug local más frecuente de todas: los formatos escritos a mano se rompen en silencio en cualquier idioma que no sea el de origen — mes y día invertidos, separadores decimales y de millares que cambian, el símbolo de moneda en el lado equivocado. La corrección estándar es dejar de escribir cadenas y pasar a formateadores conscientes del idioma, verificados en CI, como ilustra la guía 2026 de formateo i18n de una plataforma de localización. Es el control que hace imposible nuestra tercera clase: no hay forma de equivocarse en un formato que no escribes.

Aguas arriba hay una técnica que vale la pena conocer aunque no hagas software: la pseudolocalización, explicada por la guía de una plataforma de gestión de traducciones — se renderiza la interfaz con cadenas falsas, alargadas y acentuadas, antes de que exista una traducción real, de modo que los puntos que se rompen salten mientras construyes. Está pensada para las cadenas de interfaz más que para el texto editorial: cubre tu aplicación, no tus artículos.

Tres trampas que nuestra pipeline está construida para interceptar

Tres condiciones que hoy, en las 31 publicaciones que preceden a esta y en los cinco idiomas, salen coherentes. Las enumeramos igualmente: son el tipo de cosa que se rompe sin hacer ruido, y un control se construye antes de que haga falta.

• El orden de los archivos por idioma no está garantizado. El archivo neerlandés de las descripciones de los artículos enumera las entradas en un orden distinto al italiano. Ningún problema hoy — pero cualquier automatización que dé por hecho que «la línea N en italiano se corresponde con la línea N en neerlandés» está mal por construcción. Se alinea por clave, nunca por posición.
• El francés escribe los porcentajes con un espacio antes del signo — «180 %», «70 %» — donde el italiano escribe «180%». Consecuencia: una regex escrita mirando el texto italiano se salta el francés sin avisar de nada. No encuentra cero ocurrencias de forma ruidosa: encuentra menos, y parece que todo va bien. Cualquier barrido sobre texto multilingüe hay que escribirlo sobre la unión de las convenciones.
• Nuestro control sobre el colofón se evalúa por idioma. Así está bien — pero significa que una cita presente en italiano y caída en neerlandés partiría la afirmación sobre las fuentes entre dos idiomas sin disparar nada global. El control existe porque esa asimetría es posible.

La checklist, ordenada por riesgo y no a tarifa plana

Traducido a operaciones, para cualquiera que publique contenidos multilingües generados con IA:

1. Clasifica por riesgo, antes que ninguna otra cosa. Los artículos sobre materia legal, fiscal o regulatoria, o que nombran casos e instituciones reales, no reciben el mismo trato que una guía operativa: control estilo back-translation sobre las frases que afirman algo, idealmente lectura nativa completa.
2. Bloquea la terminología por idioma antes de la transcreación, con la lista de las formulaciones prohibidas — verbos que atribuyen conductas, afirmaciones de perímetro — y las infracciones señaladas antes de que el texto llegue a un revisor.
3. Separa el fact-check de la afirmación de la verificación de la traducción. El fact-check se hace sobre la fuente italiana, antes del fan-out. Abre el enlace y lee la página citada contra la afirmación: la peor clase de error es aquella en la que un dato verificable y uno inventado están en la misma frase, donde el spot-check «¿cita fuentes reales?» pasa y la afirmación sigue siendo falsa. Cómo declarar todo esto al lector es el tema del artículo sobre qué decir a los clientes sobre el uso de la IA.
4. Muestrea el 10% con revisión nativa, subiendo la cuota en los contenidos de riesgo. Es la desviación al alza la que hace que el muestreo sea útil en vez de tranquilizador.
5. Haz pasar fechas, números y monedas por un formateador consciente del idioma, controlado en build. Cero cadenas de fecha escritas a mano por idioma.
6. Grep del patrón, no del archivo. Cada vez que corrijas un defecto estructural — una comparación con una cadena de origen, una suposición posicional, una regex calibrada sobre el italiano — busca el patrón en todo el código antes de cerrar. Es el control más barato de la lista y es el que más nos ha costado no hacer.
7. Pon una fecha de revisión visible en los artículos corregidos. Nosotros ya lo tenemos en producción: es como los programas de calidad lingüística declaran un problema en vez de arreglarlo a escondidas, y para quien lee es la diferencia entre un sitio que se corrige y uno que espera que nadie se dé cuenta.

Ninguna de estas cinco clases es un argumento contra la transcreación con IA: son el coste de gestión de una capacidad que hasta hace poco no existía a este precio, y ese coste se paga en proceso, no en traductores. La pregunta correcta antes de publicar no es «¿la traducción es buena?», es «¿qué se rompería sin que nadie me avise?» — porque los defectos que cuentan están ahí: no en la frase equivocada, sino en la frase correcta renderizada por un código que habla un solo idioma.

Las fuentes externas citadas aquí son guías de proveedores de servicios de localización, blogs de plataformas i18n y la documentación del organismo que mantiene la taxonomía MQM, consultadas el 29 de julio de 2026: no son investigación científica ni literatura revisada por pares. Las normas ISO 5060:2024 e ISO 11669:2024 se citan por su nombre a partir de esas guías, sin consulta del texto normativo. El mapeo de los defectos observados en nuestra pipeline sobre las dimensiones del framework MQM es un análisis nuestro, no un resultado citado por terceros. En las fuentes consultadas no existe ninguna tasa de defectos medida para la transcreación con IA sobre copy legal o regulatorio: aquí no se recoge ningún porcentaje de ese tipo, y desconfía de quien te ofrezca uno.