Lo que la ruta de la petición puede demostrar
El primer año del AI Act fue cumplimiento sobre el papel. Desde el 2 de agosto de 2026 se aplican las competencias sancionadoras de la Comisión sobre la IA de propósito general, las obligaciones de transparencia del artículo 50 y el régimen de sanciones. Ningún componente de infraestructura le hace cumplidor — pero una parte sustancial de lo que acaba exigiendo cualquier obligación son pruebas, y las pruebas o se producen en la ruta de la petición o se reconstruyen después a un coste enorme.
Es un mapa de ingeniería, escrito para el equipo de plataforma que tiene que producir los artefactos: obligación → el artefacto que la evidencia → de dónde procede. Su clasificación de riesgo, su evaluación de conformidad y su postura jurídica son suyas y de sus asesores.
Qué cambia, exactamente
Entra en vigor
- Competencias sancionadoras de la Comisión sobre los proveedores de GPAI.
- Obligaciones de transparencia del artículo 50.
- El régimen de sanciones.
Lo que no entra en vigor
Las obligaciones de alto riesgo del anexo III se aplazaron al 2 de diciembre de 2027 en virtud del acuerdo provisional del Digital Omnibus de 7 de mayo de 2026. Constituyen una vía aparte, y quien le diga que las obligaciones de alto riesgo empiezan en agosto está trabajando con información desactualizada.
Las prácticas prohibidas se aplican desde el 2 de febrero de 2025 y las normas sobre modelos GPAI desde el 2 de agosto de 2025. Lo que llega ahora es la exigibilidad y la exposición a sanciones.
Obligación, artefacto, origen
Una tabla con la que su equipo de plataforma puede trabajar directamente. La mayor parte es lo que una ruta de petición gobernada registra de todos modos; el paquete de evidencias Enterprise lo asigna después a cada disposición como evidenciado, parcial o laguna. Los artículos 12, 14 y 26 obligan a los sistemas de alto riesgo, a partir de la fecha indicada arriba.
| Requisito de prueba | Artefacto necesario | Producido por Wäg como |
|---|---|---|
| Registro automático (art. 12) | Cada llamada al proveedor y cada rechazo, en un registro que deja ver cualquier manipulación | Libro de evidencias (open source): encadenado por hash, con puntos de control firmados con Ed25519; en modo obligatorio, sin evidencia no hay egress |
| Conservación de registros (art. 19, art. 26.6) | Registros conservados al menos seis meses, y fuera de la base de datos si hace falta | Registros de peticiones 180 días y tráfico del libro 365 días por defecto; archivo de escritura única en S3, Azure o GCS (Enterprise) |
| Trazabilidad de las decisiones automatizadas | Qué modelo atendió una petición, y por qué | x-waeg-routed-model en cada respuesta, x-waeg-route-reason cuando decidió el enrutamiento inteligente; ambos en el registro de peticiones |
| La supervisión humana es demostrable | Prueba de que los controles existen y se aplican, no son meramente orientativos | Veredictos de políticas por petición, rechazos de presupuesto que fallan en cerrado, listas de modelos permitidos |
| Anular y detener (art. 14.4, letras d y e); supervisión asignada a personas (art. 26.2) | Un responsable y aprobadores con nombre por agente; una persona aprobó la acción arriesgada o detuvo al agente | Aprobaciones de la política de herramientas y paradas por kill switch, con quién y por qué, en el libro de evidencias |
| Evidencias de agentes que un auditor puede comprobar | Ejecuciones, aprobaciones, paradas y el libro de un periodo, en un único archivo firmado | Paquetes de evidencias de agentes (Enterprise): firmados, comprobados con waeg evidence verify, con un mapping.json por disposición |
| Marcado legible por máquina del contenido generado (art. 50.2) | Marcas que un detector puede leer, y qué parte de la salida las llevaba | Enterprise: credenciales C2PA, marcas de agua, huellas de texto y un endpoint de verificación. Cada compilación registra la cobertura de marcado |
| Etiquetado del implantador (art. 50.4) | Qué respuestas están generadas o modificadas por IA | x-waeg-ai-label en cada respuesta de contenido, generada o modificada: es una indicación; lo que muestre a sus usuarios lo decide usted |
| Gobernanza y minimización de datos | Prueba de que los datos sensibles se controlaron antes de salir | Veredictos de análisis antes de la llamada, en streaming y después de la llamada, con la acción aplicada |
| Control de proveedores y ubicación | A dónde se envió cada petición, y que permaneció en jurisdicciones permitidas | Residencia (aplicar u observar), jurisdicción por petición y en el libro, registro de información en CSV o JSON |
| Reconstrucción de incidentes | Una reconstrucción de lo ocurrido, incluidos los bucles de agentes | Ejecuciones y spans de agentes, entradas del libro de llamadas a herramientas y aprobaciones; filas MCP con servidor, herramienta, latencia y error |
| Responsabilidad y titularidad | Atribución del uso a una unidad organizativa y a una persona | Jerarquía org → equipo → usuario → clave con etiquetas de imputación de costes |
| Control de cambios sobre la configuración de IA | Quién cambió qué política o presupuesto, y cuándo | Rastro de auditoría administrativa (Enterprise); cada revisión de configuración también se incorpora por hash al libro de evidencias |
| Revisión independiente | Un auditor comprueba las evidencias sin ver los prompts | Rol org_auditor (Enterprise): solo lectura, verifica y exporta el libro, sin cuerpos de petición |
| Supresión sin perder el registro (RGPD) | Los datos de una persona, desvinculados; las evidencias, intactas | Se destruyen las claves de digest por persona; la cadena sigue siendo verificable y la propia supresión queda registrada |
Las exportaciones del libro y los paquetes de evidencias se verifican sin conexión con una clave Ed25519 que usted fija (waeg ledger verify, waeg evidence verify), y el algoritmo solo necesita SHA-256 y Ed25519, así que un auditor no tiene que confiar en el sistema que los escribió. La correspondencia del paquete es una orientación para quienes evalúan el cumplimiento, no una evaluación de la conformidad ni asesoramiento jurídico.
La instrumentación de las aplicaciones no basta
El registro a nivel de aplicación produce pruebas para las aplicaciones que lo implementaron. Ese es justamente el problema: sus obligaciones recaen sobre el uso de IA de su organización, no sobre el subconjunto que alguien se acordó de instrumentar. Un control plane en la ruta de la petición produce los mismos registros para todas las cargas de trabajo situadas detrás del endpoint.
Es además la única capa que produce pruebas de aplicación en lugar de pruebas de observación. Un registro que muestra que una petición fue rechazada por infringir una política es un artefacto sustancialmente distinto de uno que muestra que fue enviada.
Lo que Wäg no hace
Wäg es infraestructura, no un programa de cumplimiento. No clasifica la categoría de riesgo de sus sistemas, no produce evaluaciones de conformidad, no mantiene la documentación técnica, no registra sistemas, no realiza evaluaciones de impacto sobre los derechos fundamentales ni determina si usted es proveedor o responsable del despliegue. Produce pruebas y aplica los controles que usted define. Todo lo demás es suyo, y en su mayor parte es un ejercicio jurídico y organizativo más que técnico.
Siete cosas que conviene hacer
- Inventaríe qué aplicaciones llaman hoy a qué proveedores — y anote cómo lo sabe, porque esa es la parte que se degrada.
- Establezca una única entrada para el tráfico de modelos, para que el inventario siga siendo cierto sin mantenimiento.
- Atribuya cada petición a una unidad organizativa y a una persona o identidad de servicio.
- Registre las decisiones de enrutamiento, no solo las peticiones. «Qué modelo atendió esto» es un hecho distinto de «esto ocurrió».
- Haga que los controles de tratamiento de datos se apliquen en lugar de ser orientativos, y registre sus veredictos en cualquier caso.
- Incluya en el alcance las llamadas a herramientas de los agentes: son la mayor laguna de pruebas en la mayoría de los entornos.
- Fije la retención de esos registros según sus obligaciones, no según su presupuesto de logs — para los registros del responsable del despliegue, al menos seis meses.
Un endpoint. Cada modelo. Control total.
Ejecútelo en su propia infraestructura
Todo lo necesario para operar un control plane en producción es Apache-2.0 y seguirá siéndolo: enrutamiento, alta disponibilidad, caché, failover, presupuestos, políticas, MCP, trabajos y observabilidad. Self-hosted, sin cuenta, sin phone-home.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>No es un pull que funcione: las imágenes aún no son públicas. Los socios de diseño reciben los datos del registro en privado.
Despliega en 5 minutosContribuya a definirlo como design partner
Wäg todavía no se ha publicado. Trabajamos con un grupo reducido de equipos que ejecutan IA multiproveedor en producción y se toman en serio la gobernanza y la soberanía, para endurecer el control plane con cargas de trabajo reales.
- Todas las capacidades Enterprise incluidas, sin coste de licencia
- Migración acompañada: la hacemos con usted, también desde LiteLLM
- Línea directa con los ingenieros que lo construyen e influencia real sobre lo que llega después