El EU AI Act suele discutirse como documento legal. Builders necesitan otra lente: qué debe existir en el repositorio, el pipeline de despliegue, la observabilidad, el proceso de review de producto y el flujo de incidentes antes de que una feature de IA llegue a producción.
El AI Act clasifica sistemas de IA por riesgo y conecta obligaciones con providers, deployers, importadores, distribuidores y otros actores. Ese vocabulario importa, pero el trabajo empieza con artefactos: inventario de sistemas de IA, registro de clasificación de riesgo, documentación técnica, evidencia de evaluación, logs, instrucciones de uso, monitoreo y ownership claro.
Esto no es asesoría legal. Es un mapa de ingeniería para conversaciones con producto, seguridad, privacidad, legal y operaciones. Los equipos fuertes no tratan compliance como un PDF al lanzar; lo tratan como ciclo de vida dentro del sistema de entrega.
La Comisión Europea describe una implementación por fases. El Act entró en vigor en agosto de 2024, con prácticas prohibidas y obligaciones de alfabetización en IA aplicables desde febrero de 2025. Gobernanza y obligaciones de IA de propósito general empezaron a aplicarse en agosto de 2025. La Comisión también trata 2026 como un año importante de aplicación, con fechas posteriores para algunos sistemas de alto riesgo después del acuerdo de simplificación de 2026.
Para builders, la lección es simple: no esperes un único deadline. Crea checks versionados de preparación que puedan adaptarse a medida que guías, códigos de práctica, estándares armonizados y alcance del producto evolucionen.
Cuando un caso de uso puede afectar empleo, educación, acceso a servicios esenciales, seguridad, migración, infraestructura crítica o comportamiento de producto relacionado con seguridad, la clasificación no es una etiqueta escondida en una planilla. Cambia la arquitectura. Necesitas inputs trazables, outputs explicables cuando corresponda, limitaciones documentadas, controles de seguridad, supervisión humana, calidad y monitoreo posterior a la salida al mercado.
La pregunta de ingeniería es: ¿puedes mostrar cómo el sistema fue construido, probado, lanzado, monitoreado y cambiado? Si no puedes, estás confiando en memoria en lugar de evidencia.
El ejercicio más útil es convertir términos de política en criterios de aceptación. "Supervisión humana" se vuelve permisos administrativos, colas de review, botones de override, audit logs, material de entrenamiento y runbooks. "Precisión y robustez" se vuelve suites de evaluación, pruebas adversariales, dashboards de monitoreo, versionado de modelo y gates de release.
| Tema regulatorio | Artefacto de ingeniería | Dónde debería vivir |
|---|---|---|
| Inventario de IA | Registro con owner, rol, provider, modelo, fuente de datos, mercado y clasificación. | Base de gobernanza y metadatos del repositorio. |
| Documentación técnica | Diagrama de arquitectura, descripción del modelo, uso previsto, limitaciones, tests y release notes. | Docs-as-code junto al servicio. |
| Gobernanza de datos | Linaje, checks de calidad, análisis de sesgo, control de acceso, retención y eliminación. | Catálogo de datos, CI y review de privacidad. |
| Supervisión humana | Cola de review, guía al operador, override, escalamiento y rollback. | UI del producto, panel admin, runbook y audit log. |
| Logs y monitoreo | Versión del modelo, clase de input, clase de output, estado de decisión, errores, abuso y drift. | Observabilidad y flujo de incidentes. |
| Gestión de cambio | Reevaluación de riesgo cuando modelo, dato, mercado, feature o provider cambia. | Template de pull request y checklist de release. |
Construiría un gateway de release para IA entre desarrollo de producto y producción. Cada feature de IA tendría que registrarse con un archivo de inventario, declarar caso de uso, apuntar a documentación de modelo y datos, definir thresholds de evaluación, exponer campos de log y pasar por policy-as-code antes del deploy.
Para equipos que usan agentes, agregaría una regla: features de IA generadas por agente no pueden mergearse si el agente no actualiza la evidencia. Si el código cambia llamada de modelo, prompt, schema, ruta de datos o flujo de decisión, inventario, tests y monitoreo deben cambiar en el mismo pull request.
La regulación de IA no es solo un plazo legal. Es presión para hacer legibles los sistemas de IA. La buena ingeniería ya quiere eso: ownership claro, comportamiento observable, cambio controlado, afirmaciones testeables y una pista de auditoría cuando algo sale mal. Los equipos que ganen van a convertir compliance en subproducto de entrega disciplinada.
Artículo sobre EU AI Act para ingeniería que cubre compliance de IA, sistemas de IA de alto riesgo, inventario de IA, gobernanza de datos, supervisión humana, logs, monitoreo, respuesta a incidentes, documentación de modelo y gates de release.