AI Gateway para EdTech: arquitectura auditable para el Reglamento de IA

Una plataforma educativa rara vez empieza con una arquitectura de IA coherente. Un equipo conecta un asistente a un proveedor, otro añade generación de cuestionarios y un tercero incorpora búsqueda sobre contenidos internos. Cada integración trae sus propias credenciales, filtros, registros y criterios para decidir qué datos pueden salir de la plataforma. El problema no es solo el modelo. Es la falta de una frontera común.

Una pasarela de IA —un AI Gateway— puede crear esa frontera. Sirve para centralizar autorización, minimización de datos, selección de proveedores, límites de uso y evidencias de cada decisión. No convierte por sí sola una plataforma en conforme con el Reglamento de IA o el RGPD. Tampoco es la única arquitectura válida. Es útil cuando aplica políticas que ya han sido definidas y cuando su diseño evita tres errores frecuentes: recuperar información antes de comprobar los permisos, llamar anonimización a un tratamiento reversible y guardar conversaciones completas como supuesto registro de auditoría.

La recomendación de este artículo se resume en cuatro reglas:

1. clasificar el caso de uso y el papel de cada actor antes de elegir la tecnología;
2. autorizar por persona, recurso y finalidad antes de consultar un sistema de generación aumentada por recuperación (RAG) o invocar una herramienta;
3. tratar los detectores como señales falibles, nunca como la frontera de autorización;
4. conservar una traza mínima que permita reconstruir el recorrido y verificar los artefactos preservados, no un almacén indiscriminado de datos personales.

La primera decisión ocurre antes de la pasarela

«EdTech con IA» no es una categoría de riesgo. El Reglamento europeo clasifica sistemas concretos a partir de su finalidad prevista y de cómo se utilizan. En educación, el anexo III incluye la admisión y la evaluación de resultados de aprendizaje. También recoge la determinación del nivel educativo y la vigilancia de conductas prohibidas durante una prueba.

Un asistente que resume un reglamento interno no plantea el mismo escenario que un sistema que modifica el itinerario de un alumno. Tampoco equivale a uno que asigna nivel o puntúa una respuesta. Antes de dibujar la infraestructura conviene completar una fila por función:

El análisis sobre IA educativa de alto riesgo desarrolla esa clasificación. Aquí importa una consecuencia arquitectónica: la política de la pasarela no puede reducirse a «educación: permitir» o «educación: bloquear». Necesita un identificador de caso de uso que enlace finalidad, riesgo, población, datos admitidos, proveedores aprobados, acciones disponibles, plazo de conservación y supervisión.

Aparecer en el anexo III tampoco cierra siempre la clasificación. El artículo 6.3 permite que el proveedor concluya que un sistema no es de alto riesgo bajo ciertas condiciones. Debe demostrar que no plantea un riesgo significativo —entre otros motivos, porque no influye sustancialmente en la decisión— y encaja en uno de los supuestos tasados. La excepción no se aplica si el sistema elabora perfiles de personas. Antes de comercializarlo o ponerlo en servicio, el proveedor debe documentar la evaluación. También debe registrar el sistema y registrarse en la base de datos de la UE. La reforma de 2026 simplificó la información de ese registro, pero no eliminó la obligación.

También hay que fijar el papel de cada organización. El artículo 25 considera proveedor al distribuidor, importador, responsable del despliegue o tercero que incurre en uno de estos supuestos:

• pone su nombre o marca en un sistema de alto riesgo ya introducido en el mercado o puesto en servicio;
• modifica de forma sustancial un sistema ya introducido o puesto en servicio, de modo que siga siendo de alto riesgo;
• cambia la finalidad de un sistema ya introducido o puesto en servicio, antes no considerado de alto riesgo, para que pase a serlo.

Un centro que utiliza el sistema puede actuar como responsable del despliegue. El mismo flujo puede involucrar además al proveedor del modelo y a encargados o subencargados del tratamiento. La pasarela debe reflejar ese reparto, no inventarlo.

La reforma europea de 2026 entró en vigor en julio de 2026. Para los sistemas del anexo III, trasladó al 2 de diciembre de 2027 la aplicación de las secciones 1, 2 y 3 del capítulo III, salvo el artículo 6.5. Ese margen no elimina el trabajo. Permite hacer lo más lento: inventariar funciones, revisar contratos, separar permisos, definir supervisión y comprobar que una decisión pasada puede reconstruirse.

En el resto del artículo, «efecto educativo material» no reproduce el criterio jurídico de «influir sustancialmente» del artículo 6.3. Es un umbral operativo: el resultado puede cambiar una calificación, la progresión, el acceso a un curso o servicio educativo, el itinerario o el inicio de una actuación disciplinaria. Si se limita a informar o proponer y una persona con autoridad decide después, no cruza por sí solo ese umbral.

Una pasarela de IA es un mecanismo de ejecución. La finalidad, la clasificación, las responsabilidades y los plazos deben existir antes como decisiones de gobierno.

Qué debe centralizar una pasarela de IA

La pasarela se sitúa entre las aplicaciones y los servicios de IA, pero no debería convertirse en una gran función monolítica. Conviene distinguir dos planos.

El plano de datos atiende cada solicitud. Comprueba identidad y permisos, aplica transformaciones, recupera fragmentos autorizados, llama al modelo, valida la respuesta y entrega o retiene el resultado. Está en el camino crítico y necesita límites de latencia, alta disponibilidad y modos de fallo explícitos.

El plano de control distribuye políticas y configuraciones. Incluye el catálogo de casos de uso, proveedores, regiones, presupuestos, detectores, esquemas de salida, conservación y revisión humana. Una modificación en este plano debe estar versionada, aprobada y poder relacionarse con las solicitudes que la usaron.

Cada caso de uso necesita además propietarios explícitos: responsable de la política, propietario de los datos o recursos, autoridad que aprueba los cambios, rol que puede anular una decisión y responsable de incidentes. La pasarela registra esas asignaciones y aplica sus permisos. No decide el reparto organizativo.

El identificador de caso de uso y la finalidad tampoco deben aceptarse como texto libre enviado por la aplicación. La pasarela los resuelve a partir del cliente y el flujo autenticados y los contrasta con el catálogo de políticas. Una finalidad declarada por el cliente es una solicitud; solo la decisión de autorización la convierte en finalidad permitida.

La traza no es un tercer filtro al final. Se abre cuando llega la petición y recoge eventos en cada etapa. Incluye autorización, transformaciones, fragmentos recuperados, ruta, controles de protección, abstención, revisión y resultado. Si el registro solo se escribe después de recibir una respuesta del modelo, desaparecen los rechazos y los fallos. Son precisamente los eventos que suelen contener la mejor evidencia para investigar.

Abrir la imagen a tamaño completo

Un recorrido razonable es este:

1. Resolver la identidad y la organización. La pasarela verifica credenciales y obtiene atributos firmados; no confía en un tenant_id enviado libremente por el cliente.
2. Autorizar la operación. Evalúa persona, rol, recurso, finalidad y caso de uso. Si falta información, deniega por defecto.
3. Clasificar y minimizar los datos. Elimina campos innecesarios y decide qué categorías pueden abandonar la plataforma.
4. Recuperar fragmentos autorizados. Aplica permisos dentro del índice, antes de devolverlos al orquestador.
5. Aplicar controles a la entrada y a los fragmentos. Separa instrucciones de datos y busca indicios de inyección o contenido no permitido.
6. Elegir una ruta aprobada. Selecciona proveedor, región, modelo y parámetros compatibles con la política.
7. Validar salida y acciones. Comprueba esquema, fuentes, reglas de negocio y permisos antes de mostrar texto o ejecutar una herramienta.
8. Reidentificar solo cuando sea necesario. Repone datos originales para un destinatario autorizado y deja constancia del motivo.

Este orden importa. Filtrar una respuesta después de haber recuperado documentos de otro centro no deshace el acceso. Moderar el texto de una herramienta no corrige una acción que ya se ejecutó. Los controles deterministas que autorizan datos o acciones deben actuar antes del componente probabilístico. Las validaciones posteriores pueden bloquear una salida, pero nunca ampliar permisos ni deshacer un acceso ya realizado.

Autorizar, minimizar y seudonimizar

Autenticar responde a «quién eres». Resolver la organización responde a «en qué ámbito trabajas». Ninguna de las dos cosas responde a «puedes usar este dato para esta finalidad». La autorización tiene que llegar hasta el recurso: curso, grupo, expediente, documento o herramienta.

En un sistema RAG, esta separación obliga a filtrar dentro de la consulta. El índice debe conservar metadatos de acceso y aplicar las listas de control antes de seleccionar fragmentos. Recuperar primero y ocultar después amplía la frontera de confianza y puede exponer información al modelo, a la memoria del orquestador o a los registros. El mismo principio se aplica a cachés, herramientas y resultados intermedios.

Después llega la minimización. Si la solicitud pide explicar un concepto, probablemente no necesita nombre, correo, identificador de matrícula ni centro. Esos campos pueden eliminarse o sustituirse antes de llamar a un proveedor externo. Presidio y herramientas parecidas ayudan a detectar y transformar entidades, pero no garantizan encontrar todos los datos sensibles. Las expresiones regulares tampoco reconocen la identificación mediante detalles indirectos: «la única alumna del aula hospitalaria» puede señalar a una persona sin contener un nombre.

Cuando existe una tabla que permite recuperar el dato original, el tratamiento es seudonimización, no anonimización. Los datos siguen dentro del ámbito del RGPD. Una implementación reversible necesita al menos:

• marcadores no adivinables, ligados a una organización, una sesión y un destinatario;
• una tabla de correspondencias cifrada y separada del texto seudonimizado;
• acceso mínimo y registro de cada reidentificación;
• caducidad explícita y destrucción verificable;
• pruebas de falsos negativos con lenguaje educativo real, incluidos los idiomas del centro.

No todos los datos necesitan el mismo mecanismo. Un identificador que el modelo no usará puede eliminarse. Un nombre que deba reaparecer en una carta puede sustituirse temporalmente. Un atributo que altere el razonamiento quizá deba generalizarse: una fecha de nacimiento exacta puede convertirse en un intervalo de edad si eso basta para la finalidad. La política debe escoger la transformación menos reveladora que conserve la utilidad.

La evaluación de impacto relativa a la protección de datos, cuando proceda, no se resuelve instalando un detector. Debe cubrir finalidad y base jurídica, necesidad, proporcionalidad, riesgos, encargados, transferencias, conservación, derechos y medidas. La pasarela aporta controles y evidencia para esa evaluación; no la sustituye.

Los guardrails reducen riesgo, pero no conceden permisos

Un guardrail basado en reglas o en otro modelo puede fallar. También puede ser víctima de la misma inyección que intenta detectar. Por eso conviene separar controles deterministas de señales probabilísticas.

Los primeros incluyen autorización, listas de herramientas permitidas, límites de argumentos, esquemas JSON, tipos de archivo, cuotas, regiones y reglas de negocio. Una respuesta del modelo no puede ampliar esos permisos. Si un asistente propone consultar el expediente de otra persona, la herramienta debe rechazarlo aunque la frase parezca legítima.

Autorizar una acción tampoco basta para ejecutarla con seguridad. Toda operación con efectos secundarios debe llevar una clave de idempotencia, registrar si quedó pendiente, ejecutada, rechazada o compensada y definir qué ocurre cuando el resultado de un intento es desconocido. Un reintento no puede duplicar una notificación, modificar dos veces un itinerario o repetir una operación sobre un expediente.

Las señales probabilísticas ayudan a detectar inyección de instrucciones, jailbreak, toxicidad o contenido inadecuado. Deben producir una decisión trazable: detector y versión, puntuación, umbral, regla activada y resultado. Su calidad se mide por caso de uso e idioma. Una tasa global obtenida con textos en inglés no demuestra cómo funcionará con abreviaturas de docentes, faltas de ortografía de alumnos o materiales multilingües.

El contenido recuperado tampoco es fiable por defecto. Una página, un PDF o un mensaje pueden contener instrucciones dirigidas al modelo. Conviene separar con estructura las instrucciones del sistema, los datos del usuario y los fragmentos recuperados; limitar las herramientas; sanear la representación final; y exigir una aprobación humana previa para ejecutar acciones que afecten a una persona. Ninguna de estas medidas elimina por sí sola la inyección. Juntas reducen su alcance.

Tampoco existe un filtro genérico que certifique la ausencia de alucinaciones. Hay que dividir el problema:

• el esquema comprueba que la salida tiene la forma esperada;
• la adecuación comprueba reglas de seguridad y tono;
• el anclaje contrasta afirmaciones con fragmentos autorizados y versionados;
• las reglas de negocio validan límites que no deben depender del modelo;
• la supervisión humana define quién vigila el funcionamiento y cuándo lo interrumpe o deriva; la revisión humana examina un caso concreto cuando falta evidencia o la salida puede tener un efecto educativo material.

Si una respuesta no puede sostenerse con las fuentes requeridas, la salida correcta puede ser una abstención. «No dispongo de evidencia suficiente» es una función del sistema, no un error que deba ocultarse. En un caso con efecto educativo material, la revisión humana necesita información, tiempo, autoridad y capacidad real para confirmar, modificar o anular el resultado antes de que sea definitivo, o revertirlo si ya se aplicó.

Registrar la decisión sin crear otra base de datos personales

Cuando resulten aplicables, el artículo 12 del Reglamento de IA exige que un sistema de alto riesgo permita registrar automáticamente los acontecimientos relevantes durante su vida útil. Los artículos 19 y 26 asignan obligaciones de conservación a proveedores y responsables del despliegue cuando los registros están bajo su control: el plazo debe ser adecuado y, en principio, no inferior a seis meses, salvo que otra norma aplicable disponga algo distinto. El Reglamento no ordena utilizar almacenamiento WORM.

Esa precisión cambia el diseño. Un registro de auditoría no tiene que contener cada prompt y cada respuesta. Guardarlos por defecto puede crear una copia concentrada de información académica, conversaciones privadas y datos de menores. La telemetría de IA generativa de OpenTelemetry trata el contenido completo como una captura opcional precisamente por su sensibilidad.

El bloque siguiente materializa la traza para Ingeniería. Quien solo necesite el criterio de decisión puede saltarlo y continuar con sus límites:

{
  "event_schema_version": "1.0",
  "event_schema_ref": "schema://ai-trace/event@v1#sha256:b81...",
  "canonicalization_ref": "canon://ai-trace/json@v1#sha256:33d...",
  "event_id": "evt_01K1...",
  "trace_id": "trc_01K1...",
  "occurred_at": "2026-07-29T10:32:14.118Z",
  "tenant_ref": "tnt_7f2...",
  "authenticated_actor_ref": "act_psn_41a...",
  "affected_subject_ref": "sub_psn_83a...",
  "client_principal_ref": "cli_app_9d2...",
  "authenticated_flow_ref": "flow://authenticated/flw_01K1...#sha256:42f...",
  "operation": "learning_support.explain_authorized_material",
  "resource_refs": ["res_course_7b1...", "res_doc_52..."],
  "use_case": {
    "id": "learning-support-summary",
    "purpose": "explicar_material_autorizado",
    "resolved_from": "flow://authenticated/flw_01K1...#sha256:42f...",
    "risk_assessment_version": "2026-07-03"
  },
  "decisions": [
    {
      "stage": "authorization",
      "decision_ref": "authz://decisions/adz_01K1...#sha256:71e...",
      "engine_ref": "authz://engines/course-access@rev-12#sha256:9d4...",
      "policy_bundle_ref": "policy://learning-support/pol_18#sha256:4b2...",
      "effective_role_refs": ["authz-role://rr_71c...@v3"],
      "attribute_evidence_ref": "authctx://snapshots/ctx_01K1...#sha256:5c2...",
      "outcome": "allow",
      "reason_code": "ROLE_RESOURCE_PURPOSE_MATCH"
    },
    {
      "stage": "data_minimization",
      "engine_version": "pii_es_7",
      "outcome": "transform",
      "reason_code": "DIRECT_IDENTIFIERS_REMOVED"
    }
  ],
  "route": {
    "provider": "approved-provider-eu",
    "effective_region": "eu-approved-region-a",
    "requested_model": "model-family-a",
    "effective_model_ref": "model://approved-provider-eu/deployment_42@rev-2026-07-19#sha256:8af...",
    "provider_response_id": "resp_01K1...",
    "route_policy_ref": "route-policy://learning-support/rp_7#sha256:2a4...",
    "reason_code": "POLICY_REGION_MODEL_MATCH",
    "prompt_template_ref": "prompt://learning-support/pt_19:v3#sha256:c31...",
    "effective_parameters_digest": "sha256:6d8..."
  },
  "retrieval": [
    {
      "chunk_ref": "doc_52:v4#c18",
      "content_fingerprint": {
        "algorithm": "HMAC-SHA256",
        "key_id": "audit-tnt7f2-2026q3",
        "value": "6aa..."
      }
    }
  ],
  "control_coverage": [
    {
      "control": "retrieval_authorization",
      "status": "executed",
      "outcome": "partial_allow",
      "decision_ref": "authz://decisions/ret_01K1...#sha256:4e3..."
    },
    {
      "control": "retrieval_resource_authorization",
      "status": "executed",
      "outcome": "reject",
      "candidate_ref": "res_doc_91c...",
      "reason_code": "RESOURCE_SCOPE_MISMATCH"
    },
    {
      "control": "input_guardrail",
      "status": "executed",
      "outcome": "pass",
      "control_ref": "guardrail://input/gi_4@rev-7#sha256:2f1..."
    },
    {
      "control": "output_validation",
      "status": "executed",
      "outcome": "pass",
      "control_ref": "validator://learning-support/out_3@rev-4#sha256:6c7..."
    },
    {
      "control": "tool_execution",
      "status": "not_applicable",
      "reason_code": "TOOL_NOT_REQUESTED"
    }
  ],
  "disposition": "delivered",
  "human_review": {
    "status": "not_required",
    "reason_code": "ADVISORY_OUTPUT_NO_EDUCATIONAL_DECISION",
    "rule_ref": "review://learning-support/advisory-summary:v2"
  },
  "input_fingerprint": {
    "algorithm": "HMAC-SHA256",
    "key_id": "audit-tnt7f2-2026q3",
    "value": "56c..."
  },
  "output_fingerprint": {
    "algorithm": "HMAC-SHA256",
    "key_id": "audit-tnt7f2-2026q3",
    "value": "9e1..."
  },
  "persistence": {
    "status": "confirmed",
    "receipt_ref": "ledger://receipts/rcp_01K1...#sha256:7a1...",
    "signature_ref": "sig://events/evt_01K1...#sha256:b9d...",
    "chain": {
      "previous_event_digest": "sha256:21b...",
      "head_ref": "ledger://chains/tnt_7f2.../heads/head_01K1...#sha256:3e5...",
      "sequence_ref": "ledger-sequence://tnt_7f2.../seq_01K1..."
    }
  },
  "retention": {
    "event": {
      "class": "operational-trace",
      "starts_from": "event_closed",
      "policy_ref": "retention-policy://events/rp_3#sha256:17c..."
    },
    "authorization_context": {
      "class": "authorization-evidence",
      "starts_from": "authorization_decision_recorded",
      "policy_ref": "retention-policy://auth-context/rp_6#sha256:28d..."
    },
    "provider_reference": {
      "class": "provider-reference",
      "starts_from": "event_persisted",
      "policy_ref": "retention-policy://provider-refs/rp_2#sha256:39e..."
    }
  }
}

El ejemplo está abreviado: evita credenciales, atributos y contenido en claro. Las referencias seudonimizadas al actor, la persona afectada, el cliente y los recursos siguen siendo datos personales y requieren finalidad, acceso y conservación propios. El evento permite reconstruir la autorización registrada, la minimización aplicada y la ruta elegida; no demuestra que se ejecutaran todos los controles previstos ni que la cobertura sea completa. En producción, cada etapa debe registrar por separado el estado (se ejecutó, no se ejecutó, falló o no era aplicable) y el resultado (permitir, permitir parcialmente, rechazar, pasar o bloquear), con el motivo y las referencias inmutables y resolubles.

La confirmación de persistencia, la firma y el encadenado permiten comprobar que el evento registrado pertenece a una secuencia verificable, no que el sistema registrara toda la verdad. Cada clase de conservación resuelve por separado su inicio, plazo y regla de borrado. Una huella no permite recuperar una entrada ni garantiza que el mismo modelo produzca de nuevo la misma salida.

Las huellas de entrada, salida y fragmentos privados emplean un código de autenticación con clave sobre una serialización canónica. La clave se acota por organización o caso de uso. Tiene identificador, rotación, acceso restringido y un plazo compatible con la verificación prevista. Esto dificulta confirmar por fuerza bruta entradas previsibles y evita correlacionarlas entre ámbitos. No anonimiza ni cifra el contenido. Cada caso de uso debe decidir si necesita preservar la versión exacta de un documento o alguna evidencia adicional. Ese material requiere acceso y plazos propios.

Una huella aislada solo demuestra que unos bytes coinciden con otros dentro del mecanismo definido. No prueba quién creó el evento, cuándo ocurrió, si falta otro evento o si el sistema registró la verdad. Frente al riesgo de alterar, insertar u omitir eventos, el diseño puede combinar firma, encadenado o árboles de Merkle, sello de tiempo y una cuenta de escritura separada. El modelo de amenazas debe distinguir cliente malicioso, administrador privilegiado, pasarela comprometida y proveedor externo, además de señalar quién puede acceder a las claves HMAC, la cola y el almacén de eventos. El control de lectura y la verificación periódica se ajustan a esas fronteras.

WORM puede ser una medida útil cuando se necesita impedir la modificación durante un plazo acordado. Amazon S3 Object Lock ofrece políticas de este tipo. La configuración debe especificar alcance, modo, periodo, permisos, claves y pruebas de recuperación. Bloquear de forma irreversible contenido personal durante años, solo porque la función existe, puede chocar con la minimización y la limitación del plazo de conservación.

Separaría al menos cuatro clases:

Así, borrar la tabla de correspondencias no obliga a destruir la evidencia técnica, y proteger la evidencia no convierte toda conversación en permanente.

Cómo debe fallar cada control

La degradación controlada no consiste en continuar sin seguridad. Cada componente necesita un comportamiento decidido de antemano.

El proveedor alternativo no puede escogerse solo porque acepte la misma API. Puede cambiar la región, la retención, la reutilización de datos, el modelo, el comportamiento y los sesgos. Cuando el resultado pueda tener un efecto educativo material, sustituirlo en silencio impide reconstruir la decisión con fidelidad.

La pasarela también concentra secretos y disponibilidad. Debe limitar las consecuencias de una intrusión o una caída con separación entre planos, credenciales de corta duración, cuotas por organización, cortacircuitos, despliegue redundante y recuperación ensayada. Si una pasarela central no puede cumplir los requisitos de residencia, aislamiento o latencia, puede ser mejor dividirla por dominio o mantener determinados controles junto a la aplicación.

Elegir herramientas por contrato, no por catálogo

Un catálogo de productos no es una arquitectura. Las capacidades, licencias y valores por defecto cambian. En AI Proxy, registrar los mensajes completos de solicitud y respuesta es opcional y configurable. Por separado, el evento de auditoría de AI PII Sanitizer puede incluir los valores originales de los campos saneados salvo que se active skip_logging_sanitized_items para omitirlos. La selección debe partir de un contrato estable:

Con este contrato, una herramienta puede sustituirse sin redefinir lo que significa autorizar, bloquear o registrar. También permite probar las limitaciones declaradas por cada proyecto en lugar de asumir que el nombre de una función equivale a una garantía.

Desplegar en cuatro pasos y con pruebas de aceptación

Empezaría con un único caso de uso acotado y cuatro fases:

1. Observar solo rutas existentes y ya autorizadas. Durante un periodo acotado, la pasarela registra metadatos mínimos sobre la política que habría aplicado, sin habilitar casos nuevos ni rebajar controles previos. Esta fase descubre rutas y dependencias que el inventario no recogía.
2. Simular. Se prueban bloqueos, abstenciones, fallos y revisiones con tráfico representativo, sin afectar a decisiones reales.
3. Aplicar límites deterministas. Se activan autorización, aislamiento, esquemas, cuotas y proveedores aprobados antes de delegar decisiones a clasificadores.
4. Ampliar por caso de uso. Cada nueva función incorpora su política, evaluación de impacto, pruebas, supervisión y retención; no hereda un permiso genérico.

No fijaría umbrales universales en un artículo. Cada prueba debe declarar el corpus y su versión, el umbral local, quién lo aprueba, si el resultado bloquea el despliegue y cuándo caduca esa aceptación. Sí exigiría resultados medidos para estas pruebas:

• ningún acceso cruzado entre organizaciones en la batería adversarial;
• tasa de fugas y falsos bloqueos del detector con datos educativos representativos;
• ataques directos e indirectos mediante mensajes, documentos y fragmentos RAG;
• rechazo de acciones y argumentos fuera del permiso, aunque el modelo los solicite;
• reintentos, respuestas tardías y entregas duplicadas sin efectos repetidos;
• reconstrucción de una decisión con las versiones exactas de política, modelo y fuentes;
• caída de cada componente sin eludir los controles;
• sustitución de proveedor solo dentro de rutas preaprobadas;
• latencia, coste, disponibilidad y recuperación dentro del presupuesto del caso de uso;
• revisión humana con información, tiempo, autoridad y posibilidad de revertir.

La pregunta final no es si la pasarela tiene «guardrails». Es si el equipo puede explicar qué identidad y finalidad autorizaron el acceso, qué política eligió el proveedor y las fuentes, quién aprobó la acción y qué hizo el sistema cuando falló cada paso.

Definiría primero la política, el esquema de eventos y la matriz de fallos. Después elegiría los productos. Una pasarela bien diseñada hace aplicables y auditables las políticas comunes de una plataforma educativa. Una pasarela que solo encadena filtros y almacena conversaciones añade latencia, concentra riesgo y conserva más datos sin resolver quién autoriza cada uso, con qué finalidad y qué ocurre cuando falla.