Un producto de software con inteligencia artificial que se vende en varios países hispanohablantes falla casi siempre por los mismos seis puntos, y ninguno se arregla traduciendo la interfaz: dónde residen los datos y dónde corre la inferencia, qué norma local exige qué, en qué moneda y por qué medio se cobra, qué documento electrónico obliga cada administración, qué identificadores y formatos usa cada país y sobre qué corpus responde el motor. Traducir cambia el idioma; localizar cambia el comportamiento. Este artículo describe los seis requisitos y cómo comprobar cada uno antes de firmar, desde la experiencia de operar 12 plataformas con IA en producción en varios países de la región.
Por qué la traducción crea una falsa sensación de encaje
La versión traducida de un producto extranjero se ve bien en la demostración: los menús están en español, los ejemplos usan nombres locales y el comercial responde en la zona horaria correcta. El problema aparece en el segundo mes, cuando alguien intenta emitir un documento válido, registrar a un cliente con su identificador real o responder al área legal dónde se procesan los datos.
La razón es estructural. Traducir es una capa de presentación; los seis requisitos que siguen viven en la lógica del producto: en el modelo de datos, en la integración con la administración tributaria, en el flujo de cobro y en el corpus sobre el que responde el motor. Cambiar cualquiera de ellos después del lanzamiento cuesta mucho más que haberlo previsto, y por eso conviene preguntarlo antes de firmar y no después del primer incidente.
Requisito 1: dónde residen los datos y dónde corre la inferencia
Son dos preguntas, no una, y la segunda es la que casi nunca se hace. El almacenamiento puede estar en el país mientras el modelo que procesa los fragmentos se ejecuta en otro; en ese caso hay tratamiento en el extranjero aunque los datos «vivan» localmente, y eso activa las reglas de transferencia internacional. En Chile la Ley 21.719 regula la transferencia internacional de datos personales y las obligaciones del encargado del tratamiento1; en México, la ley federal de datos en posesión de particulares fija su propio régimen2; en Colombia lo hace la Ley 1581 de 20123; y en España y la Unión Europea, el RGPD4.
Lo que hay que pedir es concreto: la lista de terceros que participan en la inferencia, con su país y el alcance exacto de lo que reciben. Ese documento existe y tiene nombre: es el inventario de componentes de IA. Un proveedor que no puede entregarlo no está en condiciones de responder la pregunta.
Requisito 2: qué norma aplica en cada país donde opera la empresa
Si la empresa opera en varios países, el contrato no puede escribirse contra la norma del país donde está el servidor: debe obligar al proveedor al requisito más exigente de todos los que le apliquen, en particular en plazos de notificación de incidentes. Es más simple de operar y evita descubrir en un incidente que el plazo contractual era el equivocado.
El cuadro comparado por jurisdicción —datos personales y transferencia, ciberseguridad e incidentes, regulación específica de IA— con la fuente primaria de cada país está en la tabla de marco legal del artículo pilar. Conviene añadir una regla de futuro: donde todavía no hay ley específica de IA, el contrato debe incluir el deber de adecuarse a la que entre en vigor, porque llega. El Reglamento europeo de inteligencia artificial ya fija un calendario escalonado de aplicación5.
Requisito 3: moneda de cobro y medio de pago
Cobrar en divisa cuando los ingresos del cliente están en moneda local traslada el riesgo cambiario íntegro al comprador: el precio del servicio sube sin que el proveedor haya cambiado nada. Es un punto de negociación legítimo y suele resolverse fijando el precio en moneda local, o en una unidad indexada donde exista, con una regla de ajuste escrita.
El medio de pago es un asunto distinto y más operativo. Buena parte de los clientes de la región no dispone de tarjeta de crédito internacional, y cada país tiene sus rieles habituales: transferencias interbancarias inmediatas, sistemas de pago del banco central, pasarelas locales, efectivo referenciado. Un producto que solo acepta tarjeta en divisa no está siendo estricto: está renunciando a un tramo grande de su mercado. La forma práctica de plantear el precio a varias monedas está tratada en pricing de SaaS con monedas locales.
Requisito 4: el documento electrónico obligatorio de cada país
Casi todos los países de la región han hecho obligatoria alguna forma de documento tributario electrónico, con formatos, plazos y calendarios distintos. Un producto que factura, cobra o registra operaciones tiene que emitir el documento que la administración de ese país acepta, no un PDF con aspecto de factura.
En México, el Código Fiscal de la Federación regula los comprobantes fiscales digitales por Internet en su artículo 29, con requisitos de certificación y timbrado6. En España, la Ley 18/2022 —conocida como «Crea y Crece»— establece la obligación de factura electrónica en las operaciones entre empresarios y profesionales, con despliegue escalonado7. Chile opera con documentos tributarios electrónicos ante el Servicio de Impuestos Internos; Colombia, con factura electrónica de venta ante la DIAN; Perú, con comprobantes de pago electrónicos ante la SUNAT; Argentina, con comprobantes electrónicos ante su administración federal. Las tres últimas se citan aquí por su nombre oficial, sin enlace, por el motivo indicado en el aviso anterior.
La pregunta operativa para el proveedor no es «¿soportan facturación electrónica?» sino «¿en qué países emiten el documento oficial hoy, con qué versión del esquema, y qué pasa cuando la administración publica una versión nueva?». La segunda parte es la que separa una integración viva de una que funcionó una vez.
Requisito 5: identificadores y formatos locales
Cada país identifica a personas y empresas de una manera, con longitudes, dígitos verificadores y reglas propias. Tratar ese campo como texto libre parece inofensivo y produce dos daños concretos: registros duplicados de un mismo cliente y documentos rechazados por la administración.
| País | Identificador tributario o de persona más usado | Consecuencia de no validarlo |
|---|---|---|
| México | RFC (y CURP para personas físicas) | Comprobante rechazado en la certificación |
| Chile | RUT con dígito verificador | Duplicados y documentos tributarios inválidos |
| Colombia | NIT (con dígito de verificación) y cédula | Rechazo de la factura electrónica de venta |
| Perú | RUC y DNI | Comprobante electrónico no aceptado |
| Argentina | CUIT y DNI | Comprobante electrónico no aceptado |
| España | NIF y CIF | Factura no válida a efectos fiscales |
A la lista hay que sumar lo que casi siempre se olvida: formato de fecha, separador decimal, estructura de dirección, husos horarios y el hecho de que los números de teléfono móviles de algunos países incorporan dígitos adicionales según el canal por el que llegan. Cada uno de esos detalles ha roto una integración real en algún momento; ninguno se detecta traduciendo cadenas de texto.
Requisito 6: sobre qué corpus responde el motor de IA
Este es el requisito específico de los productos con inteligencia artificial y el más caro cuando falla, porque el fallo no se ve. Un motor que responde sobre normativa, procedimientos o prácticas de otro país produce respuestas bien redactadas, seguras y equivocadas de jurisdicción. Nadie las corrige leyendo, porque suenan correctas.
Lo que hay que exigir es la ficha del corpus: qué fuentes está indexadas, de qué país, con qué fecha de corte y qué queda explícitamente fuera. Y la prueba se hace en la demostración, con dos consultas: una cuya respuesta correcta dependa de la norma de su país, y otra cuya respuesta correcta sea «esa norma no existe en esta jurisdicción». Un sistema serio se abstiene en la segunda. El método completo de comprobación está en cómo se verifica una cita generada por IA, y la forma de exigir la tasa medida, en cómo medimos las alucinaciones de una IA en producción.
Cómo comprobar los seis en una sola sesión
| # | Requisito | Qué pedir en la demostración |
|---|---|---|
| 1 | Datos e inferencia | El inventario de terceros con país y alcance del acceso |
| 2 | Norma aplicable | El plazo de notificación de incidentes comprometido y contra qué norma |
| 3 | Cobro | Precio en moneda local por escrito y los medios de pago admitidos por país |
| 4 | Documento electrónico | Un documento real emitido para su país y la política ante un cambio de esquema |
| 5 | Identificadores | Un alta con un identificador local mal formado: debe rechazarlo con un mensaje claro |
| 6 | Corpus | Dos consultas: una que dependa de la norma local y otra que no exista en su jurisdicción |
Ninguna de las seis exige conocimientos técnicos para pedirla, y las seis producen una respuesta que se puede archivar. Un proveedor que declara con honestidad cuáles cumple hoy y cuáles no, con fechas comprometidas, es una señal mejor que uno que responde afirmativamente a todo. Los nichos donde esta diferencia pesa más están descritos en cinco nichos de mercado mal atendidos, y si quiere revisar un caso concreto puede plantearlo aquí.
-
Ley 21.719, Biblioteca del Congreso Nacional de Chile. Verificado el 17 de agosto de 2026 contra el servicio XML de intercambio de normas de LeyChile: publicación del 13 de diciembre de 2024, sin derogación registrada. ↩
-
Cámara de Diputados del H. Congreso de la Unión (México), Ley Federal de Protección de Datos Personales en Posesión de los Particulares, texto vigente con última reforma publicada en el D.O.F. el 14 de noviembre de 2025. Consultado el 17 de agosto de 2026. ↩
-
Ley 1581 de 2012 (Colombia), régimen general de protección de datos personales. Consultado el 17 de agosto de 2026. ↩
-
Reglamento (UE) 2016/679. Consultado en EUR-Lex el 17 de agosto de 2026. ↩
-
Reglamento (UE) 2024/1689 de inteligencia artificial. Consultado en EUR-Lex el 17 de agosto de 2026. ↩
-
Cámara de Diputados del H. Congreso de la Unión (México), Código Fiscal de la Federación, artículo 29. Consultado el 17 de agosto de 2026. ↩
-
Ley 18/2022, de 28 de septiembre, de creación y crecimiento de empresas; texto consolidado del Boletín Oficial del Estado. Consultado el 17 de agosto de 2026. ↩