La certificación de IA se convierte en un pasaporte al mercado
сертификация ИИEU AI ActISO/IEC 42001
No todos los modelos necesitan certificado
No describiría la situación actual como una concesión universal de licencias para la IA: a 25 de septiembre de 2026 no existe tal régimen. Sin embargo, la idea de que un producto serio no llegará al mercado sin un cumplimiento demostrable ya no parece una previsión, sino una descripción de la contratación y la regulación.
La Unión Europea fija en el EU AI Act un umbral concreto para los sistemas de alto riesgo cubiertos por la norma. Antes de su comercialización, necesitan documentación técnica, gestión de riesgos, supervisión humana, información sobre rendimiento y sesgos, además de una evaluación de conformidad. Es un procedimiento obligatorio, pero no un certificado universal para cada modelo.
Para los sistemas generativos, el artículo 50 establece obligaciones de transparencia desde el 2 de agosto de 2026. Para determinados sistemas ya existentes, el período transitorio de las obligaciones de etiquetado termina el 2 de diciembre de 2026. En la fecha de esta publicación, el primer plazo ya pasó y el segundo aún no: el calendario regulatorio no es una teoría.
ISO/IEC 42001 resuelve otro problema: es una norma certificable para un sistema de gestión de IA y cada vez se considera más una prueba de la madurez del proveedor. AI RMF 1.0 y AI 600-1 de NIST ofrecen marcos para gestionar riesgos, pero por sí solos no crean un certificado. En Estados Unidos, según el resumen citado de la orden federal de 2026, el intercambio anticipado de información sigue siendo voluntario y se excluye expresamente la licencia federal obligatoria para modelos nuevos.
Por qué el mercado pide certificados de todos modos
Para un comprador corporativo, la diferencia entre una obligación legal y una norma voluntaria se difumina rápidamente: si el proveedor no puede demostrar que controla su sistema, resulta más sencillo excluirlo de la compra. Por eso ISO/IEC 42001 se convierte no en una licencia legal, sino en un filtro práctico de entrada.
Mi conclusión como ingeniero es simple: no se revisará un documento bonito en la pared, sino la coherencia de las pruebas. El propósito del modelo, el origen de los datos, las limitaciones conocidas, los resultados de pruebas de sesgo, la evaluación de riesgos, los controles humanos y los registros de despliegue deben formar una imagen auditable.
Ganan los equipos que integran la recopilación de estas evidencias en el desarrollo, en lugar de preparar una carpeta justo antes de una auditoría. Pierden los modelos cerrados y los proveedores capaces de mostrar solo métricas, sin contexto de uso ni controles.
Un certificado no demuestra que un modelo sea bueno. Pero la ausencia de huellas verificables demuestra cada vez más que no se le debe confiar un entorno operativo crítico.