Las funciones de IA ya forman parte de la mayoría de los productos: un asistente de chat en la página de ayuda, una búsqueda con IA dentro de una tienda, descripciones de producto generadas, un panel de recomendaciones. Cada una puede responder de forma distinta según dónde esté el usuario, y esas diferencias rara vez aparecen cuando el equipo prueba desde la oficina. Si tu producto da servicio a varios mercados, revisar la respuesta de la IA por país debe ir junto a tu trabajo de IA y machine learning y a tus pruebas de release, no después de una queja de un mercado.
Esta guía explica por qué la respuesta de la IA cambia según el país, qué revisar, cómo hacer que las peticiones de prueba parezcan las de un usuario local y cómo comparar respuestas que nunca son iguales palabra por palabra.
Por qué la respuesta de la IA cambia según el país
La mayoría de las diferencias vienen del producto que rodea al modelo, no del modelo en sí:
- La ubicación como contexto. Muchos asistentes añaden al prompt el país o la ciudad del usuario, leídos a partir de la IP. Una geolocalización errónea da una respuesta segura de sí misma para el mercado equivocado.
- Enrutamiento regional. Las peticiones pueden ir a un modelo, una versión o un endpoint distinto según la región, a menudo por motivos de residencia de datos. Dos mercados pueden ejecutar versiones distintas del modelo el mismo día.
- Feature flags. Las funciones de IA suelen lanzarse país por país. Un botón que funciona en un mercado puede faltar o fallar en otro.
- Reglas de políticas y cumplimiento. Las normas locales sobre salud, finanzas, elecciones o edad pueden provocar negativas o avisos legales solo en algunos países.
- Recuperación. Cuando el asistente busca en la web, en un centro de ayuda o en un catálogo de productos, suele hacerlo con la región del usuario, así que cambian los datos y los productos que cita.
El primero y el último dependen de la IP de la que sale la petición. Por eso las pruebas desde una sola ubicación no los detectan.
Qué revisar en cada mercado
En cada mercado en el que operas, revisa el mismo conjunto de propiedades:
| Comprobación | Qué puede fallar |
|---|---|
| Idioma | Respuestas en inglés a un usuario en Japón, o idiomas mezclados en una misma respuesta |
| Moneda y unidades | Precios en dólares para un usuario alemán, millas en lugar de kilómetros |
| Datos locales | Plazos de envío, festivos, normas fiscales o ubicaciones de tiendas incorrectos para ese país |
| Disponibilidad de funciones | La función de IA está oculta, da error o muestra un mensaje de “no disponible en tu región” |
| Comportamiento de las políticas | Negativas o avisos que deberían aplicarse en un país aparecen en todos, o al revés |
| Productos y fuentes | Recomendaciones o citas de artículos que no se venden o no son relevantes en ese mercado |
| Formato | Fechas, números y direcciones en un formato local incorrecto |
Varias de estas comprobaciones coinciden con las revisiones clásicas de página. Nuestra guía de QA de localización a escala cubre los textos, el hreflang y el diseño; esta lista cubre lo que añade la capa de IA.
Probar como un usuario local
La ubicación suele salir de la IP, así que la petición de prueba tiene que salir del mercado. Enviarla a través de proxies residenciales segmentados en el país hace que el producto aplique la misma detección de región, los mismos flags y las mismas políticas que aplica a un usuario real de allí. Las bases de datos de IP suelen asignar los rangos de centros de datos al país equivocado, o estos acaban detrás de controles antibots, lo que te da resultados de prueba que nadie en ese mercado vería.
Ajusta también el resto de la petición al mercado: la cabecera Accept-Language, la zona horaria y la configuración regional del navegador. Una IP japonesa con un navegador en inglés es un usuario distinto de una IP japonesa con un navegador en japonés, y merece la pena probar ambos. Nuestro artículo sobre cómo alinear la geolocalización del proxy, la zona horaria y la configuración regional explica cómo mantener coherentes estas señales.
En un chat de varios turnos, mantén una sola IP durante toda la conversación con una sesión sticky, para que el producto no vea al usuario moverse entre turnos:
customer-USERNAME-country-jp-sid-chat-ja-01-ttl-600:PASSWORDUn pequeño banco de pruebas
El banco de pruebas de abajo envía los mismos prompts a tu endpoint de IA desde varios mercados y revisa propiedades en lugar del texto exacto. Sustituye el endpoint y las comprobaciones por los tuyos.
import requests
GATEWAY = "p.shifter.io:443"
USER, PASS = "USERNAME", "PASSWORD"
ENDPOINT = "https://app.example.com/api/assistant"
MARKETS = {
"de": {"lang": "de-DE", "currency": "€"},
"jp": {"lang": "ja-JP", "currency": "¥"},
"br": {"lang": "pt-BR", "currency": "R$"},
"us": {"lang": "en-US", "currency": "$"},
}
PROMPTS = ["How much is shipping for a 2 kg parcel?", "Recommend a laptop under my budget."]
RUNS = 3
def ask(country, lang, prompt, run):
proxy = f"http://customer-{USER}-country-{country}-sid-ai-{country}-{run}-ttl-600:{PASS}@{GATEWAY}"
r = requests.post(ENDPOINT, json={"message": prompt},
headers={"Accept-Language": lang},
proxies={"http": proxy, "https": proxy}, timeout=60)
return r.status_code, r.json().get("answer", "") if r.ok else ""
for country, m in MARKETS.items():
for prompt in PROMPTS:
hits = 0
for run in range(RUNS):
status, answer = ask(country, m["lang"], prompt, run)
if status == 200 and m["currency"] in answer:
hits += 1
print(country, prompt[:30], f"currency ok in {hits}/{RUNS} runs")Añade una comprobación por cada fila de la tabla anterior: un detector de idioma para la respuesta, una lista de los productos que se venden en cada mercado, un patrón para el mensaje regional de “no disponible”. Lanza cada prompt varias veces, porque la respuesta del modelo varía entre ejecuciones; una comprobación que se supera en dos de tres ejecuciones es un hallazgo, no ruido.
Integrarlo en las pruebas de release
- Ejecuta el banco de pruebas tras cada cambio de modelo, de prompt o de flag, desde todos los mercados, no solo desde la región por defecto.
- Mantén un conjunto fijo de prompts por mercado, escrito por hablantes nativos, que incluya las preguntas que los clientes hacen de verdad allí.
- Guarda las respuestas con el país, la versión del modelo y la hora, para distinguir un cambio de modelo de un cambio de enrutamiento.
- Revisa las negativas por país cada semana. Una tasa de negativas que se dispara en un mercado suele apuntar a una regla de políticas o a un endpoint regional.
Si tus funciones de IA también aparecen en las búsquedas, el mismo método por mercado sirve para monitorizar la visibilidad en la búsqueda con IA, donde la pregunta es qué dicen de ti otros asistentes en cada país.
Conclusión
La respuesta de la IA es local, porque el producto que rodea al modelo lee la ubicación del usuario y actúa en consecuencia. Prueba cada mercado desde una IP residencial de ese mercado, con el idioma y la configuración regional a juego, mantén los chats de varios turnos en una sola IP sticky y revisa propiedades como el idioma, la moneda, los datos locales, la disponibilidad y las negativas a lo largo de varias ejecuciones. Hazlo en cada release y los fallos regionales de la IA dejarán de ser algo que descubren primero tus clientes.