Las obligaciones de la fase de desarrollo establecidas en la Ley de IA de la UE se traducen en trabajo de ingeniería mucho antes de que alguien redacte un informe jurídico. El curso se centra en las obligaciones de los proveedores —es decir, los deberes que recaen sobre el equipo que lanza un sistema de IA—, ya que son los ingenieros y científicos de datos quienes generan la mayor parte de las pruebas en las que se sustentan dichas obligaciones. A menudo, los equipos pasan esto por alto porque perciben el trabajo simplemente como la creación de funcionalidades, cuando el éxito o el fracaso posterior depende de lo que se haya registrado, probado y mantenido de forma coherente entre versiones. El fallo habitual no se debe a una mala intención, sino a una brecha entre lo que hace el sistema y lo que el equipo puede demostrar que hace. [fuentes][/fuentes]
Un proveedor solo puede defender un lanzamiento si el desarrollo tiene una estructura clara desde el principio. Dicha estructura comienza por definir qué sistema se está construyendo, cuál es su finalidad y qué puede o no hacer en el entorno real donde operará. También abarca los datos de entrada, los controles incorporados, los registros existentes y las acciones que puede emprender una persona cuando el resultado parece erróneo. Es fundamental analizar estos aspectos en conjunto, ya que la ausencia de algún elemento suele detectarse cuando el equipo ya ha completado las fases de entrenamiento, integración y despliegue. El siguiente mapa presenta el panorama completo antes de abordar cada una de las partes por separado. [fuentes][/fuentes]
En este curso, un sistema de IA no es simplemente un archivo de modelo o una instrucción (prompt) ingeniosa. Se trata de todo el conjunto que recibe entradas de un proceso laboral, genera resultados en los que confían las personas y se comporta de maneras determinadas por el código, los datos, la configuración y la interfaz que lo rodea. Por eso, un pequeño cambio en la canalización (pipeline) puede alterar el efecto del sistema en el mundo real, incluso si los pesos del modelo permanecen inalterados. [fuentes][/fuentes]
Un equipo puede pensar que simplemente está “integrando un modelo”, pero el objeto sujeto a regulación es el sistema completo una vez que incorpora decisiones, recomendaciones o contenido generado a un flujo de trabajo. El proceso de entrenamiento, el almacén de características (feature store), el índice de recuperación, los mecanismos de seguridad (guardrails), las reglas de monitoreo y los textos de la interfaz determinan conjuntamente qué ve el usuario y qué acciones puede realizar a continuación. Si estos elementos no están vinculados a una versión y a un propósito específicos, las pruebas y la documentación posteriores no coincidirán con lo que realmente se implementó. [fuentes][/fuentes]
Los ingenieros y científicos de datos suelen ser los responsables de las decisiones que definen el propósito previsto, las entradas y los límites del sistema, ya que dichas decisiones se toman en los tickets de trabajo, los conjuntos de datos, los planes de evaluación y las revisiones de código. Los equipos legales y de cumplimiento pueden interpretar la normativa, pero no pueden reconstruir qué datos procesó el modelo durante el entrenamiento ni qué permitía la interfaz en el momento de tomar una decisión. El equipo de producto puede establecer objetivos, pero no puede suplir la falta de registros (logs) ni repetir un experimento del que no se guardó trazabilidad. [fuentes][/fuentes]
La transferencia a los equipos de despliegue también comienza durante la fase de desarrollo. Estos equipos necesitan instrucciones claras, una interfaz que ofrezca transparencia práctica y mecanismos de supervisión eficaces incluso bajo presión, ya que un documento de políticas en PDF no puede compensar un sistema que oculta su propia incertidumbre o impide la intervención humana. Cuando los desarrolladores consideran estos aspectos como mero “papeleo posterior”, suelen terminar parcheando la interfaz y reescribiendo la documentación para ajustarla a la realidad, un proceso más lento que realizar un diseño adecuado desde el principio. [fuentes][/fuentes]
Antes de continuar, resulta útil identificar qué tipos de fallos nos resultan ya familiares. [fuentes][/fuentes]