Este curso trata sobre las decisiones de desarrollo de IA responsable dirigidas a ingenieros que lanzan sistemas de IA, basándose en la Ley de IA de la UE (Reglamento (UE) 2024/1689). Se centra en la labor del proveedor, es decir, en las decisiones que transforman un modelo o flujo de trabajo (pipeline) en un producto sólido y defendible. En este curso, la IA responsable implica diseñar, documentar, gobernar y lanzar sistemas de manera que sus límites sean claros y su comportamiento resulte controlable. El error que cometen los equipos es tratar las obligaciones del proveedor como mero papeleo añadido en el momento del lanzamiento. Aunque la tarea pueda parecer una redacción tardía de documentación, en realidad se define mucho antes, mediante decisiones sobre diseño y datos. Por ello, el curso vuelve constantemente a elementos concretos (artefactos) que pueden nombrarse y versionarse. Construimos el mapa general antes de entrar en detalles, para que puedas ubicar cada responsabilidad en su lugar correspondiente.
Un equipo proveedor ya realiza gran parte de este trabajo, aunque de forma dispersa: documentos de arquitectura, fichas de modelo (model cards), cuadernos de evaluación, listas de verificación para el lanzamiento y paneles de monitorización. El problema es que estos elementos no siempre se alinean con un propósito único y definido, lo que provoca que surjan brechas de información entre los equipos. Una vez que existen estas brechas, los responsables de la implementación posterior no pueden operar el sistema de forma segura, ya que desconocen para qué se creó o cómo se comporta bajo condiciones de estrés. El curso aborda las obligaciones del proveedor estructurándolas en un ciclo de desarrollo y lanzamiento compuesto por tres fases: diseño y datos; hitos de lanzamiento y evidencias; y, finalmente, monitorización poscomercialización y gestión de incidentes. Esta estructura es la que permite que las lecciones posteriores sean prácticas y aplicables. Aquí tienes un resumen visual de dicha estructura:
En este curso, un sistema de IA se define como un sistema basado en máquinas, diseñado para operar con distintos niveles de autonomía, que infiere cómo generar resultados —tales como predicciones, contenido, recomendaciones o decisiones— a partir de los datos de entrada que recibe. Un proveedor es la persona u organización que desarrolla un sistema de IA (o encarga su desarrollo) y lo comercializa o pone en servicio bajo su propio nombre o marca comercial, ya sea de pago o gratuito. Esta definición es relevante para los ingenieros porque es posible convertirse en proveedor sin haber entrenado los pesos base del modelo; basta con ser responsable del sistema desplegado y de su finalidad prevista. Se cruza esa línea cuando los usuarios perciben el sistema como el producto final y el equipo controla su funcionamiento.
Utilizar un modelo de terceros no convierte automáticamente a dicho tercero en el proveedor de todo lo que usted lanza al mercado. Su equipo sigue decidiendo qué datos entran, qué significan los resultados y qué mecanismos de seguridad (o salvaguardas) existen en la interfaz. Esas decisiones definen en la práctica la finalidad prevista, aunque el departamento de marketing nunca utilice esa expresión. Cuando un socio pregunta «¿Quién es el proveedor aquí?», en realidad está preguntando quién puede aportar el registro de evidencias, no quién escribió la primera línea de código del modelo.
Los ingenieros se encargan de aquellos aspectos de la labor del proveedor que solo pueden materializarse mediante la implementación técnica. Los equipos de cumplimiento normativo y legal pueden ayudar a interpretar la Ley de IA, pero no pueden añadir a posteriori sistemas de registro, puntos de supervisión o cobertura de evaluación una vez realizado el lanzamiento. La dificultad recurrente radica en traducir una obligación legal en algo concreto que pueda señalarse en un repositorio, una ejecución de pruebas o un hito de aprobación de lanzamiento. Es en esa traducción donde los proyectos suelen desviarse, ya que implica a múltiples equipos y cronogramas. Cuando el proceso funciona bien, el resultado de la ingeniería es previsible y verificable.
Un equipo que gestiona esto con éxito repite siempre la misma estrategia: define la finalidad prevista en una fase temprana y vincula a ella las decisiones de diseño y la documentación. Tratan la documentación como un reflejo fiel de la implementación —y no como una narrativa redactada a posteriori—, garantizando así que se mantenga versionada junto con el sistema. Asimismo, distinguen entre los requisitos previos a la comercialización y los aspectos operativos posteriores al lanzamiento, dado que el despliegue modifica las posibilidades de corrección a bajo coste. Si es posible identificar el artefacto asociado a una obligación, también será posible asignar un responsable y una fecha límite.
[fuentes][/fuentes]