Cómo diseñar un router de IA soberano que elija región, proveedor y fallback sin violar restricciones de datos

Paso 1 — Define una taxonomía de requisitos, no una lista de países. Para cada cliente modela allowedregions, dataresidency, keyownership, provideraccess, retention, networkegress y restricciones sectoriales. Una simple etiqueta “India” o “EU” no captura necesidades de confidential computing, soporte, backups o claves. Distingue requisitos duros de preferencias. Los duros eliminan rutas; las preferencias ordenan opciones válidas por costo o latencia. Versiona la política y vincula cada ejecución a la versión que usó. Así una auditoría puede explicar por qué un workflow fue permitido incluso si las reglas cambiaron meses después.

Paso 2 — Clasifica datos y efectos antes del routing. Identifica qué inputs contienen información sensible y cómo cambia su clasificación al transformarse. Un resumen puede seguir siendo sensible; un embedding puede conservar información recuperable; un log puede incluir contenido completo. Propaga etiquetas a artefactos derivados y tool calls. También clasifica efectos: leer una base local no es lo mismo que enviar datos a un SaaS externo. El router recibe un conjunto de requisitos acumulados del workflow. Si una fase mezcla objetos con políticas distintas, aplica la más restrictiva o separa el trabajo en subprocesos compatibles.

Paso 3 — Mantén un catálogo de capacidades verificadas por región. Para cada proveedor y runtime registra servicios disponibles, endpoints, residencia documentada, soporte de claves, acceso operativo, conectividad y certificaciones relevantes. No asumas que porque una región existe todos los productos funcionan allí. Añade fechas y fuentes a cada capacidad. Un job periódico puede detectar cambios, pero una ejecución crítica debe consultar una versión aprobada del catálogo. Cuando una capability está en rollout o preview, trátala explícitamente. La plataforma debe preferir un “no hay ruta compatible” honesto a enviar datos por un servicio cuya residencia no está confirmada.

Paso 4 — Calcula la intersección y luego optimiza. Primero elimina toda ruta que viole políticas duras. Después compara las opciones restantes por latencia, precio, modelo, capacidad y sostenibilidad. Este orden evita que un optimizador económico “compense” una violación de residencia con un costo menor. Conserva la explicación: opciones descartadas y regla que falló, opción elegida y criterio de ranking. Para workflows largos, recalcula solo en checkpoints seguros; cambiar de región a mitad de tarea puede mover contexto y logs. La política debe definir qué estado puede cruzar y qué debe permanecer donde se originó.

Paso 5 — Diseña fallbacks antes del outage. Cada ruta primaria tiene alternativas permitidas ordenadas. Si ninguna cumple, define acción: esperar, degradar a lectura local, pedir autorización o cancelar. Nunca uses un fallback global implícito. Simula fallos de región y verifica que el router se niegue a salir de scope aunque la presión de disponibilidad sea alta. Para clientes con requisitos estrictos, un error controlado puede ser preferible a una respuesta rápida fuera de jurisdicción. Registra cada fallback utilizado y su motivo; esa evidencia es fundamental para demostrar que continuidad y soberanía fueron tratadas como una misma política.

Paso 6 — Emite un sovereignty receipt. Al finalizar, guarda regiones, proveedores, servicios, política aplicada, rutas de egress y excepciones autorizadas. No incluyas secretos ni contenido sensible. Expón al cliente una vista simple y conserva detalle para auditoría. Monitorea drift entre configuración declarada y ubicación observada. En Goatify, este receipt puede acompañar habilidades de sectores regulados y facilitar expansión internacional. El mismo agente puede operar en varios países con execution plans distintos, pero todos bajo un contrato común. La soberanía deja de ser una revisión manual previa a cada proyecto y se convierte en una propiedad comprobable de cada run.