El jurista pide supervisión humana. El desarrollador añade un botón de validación. El responsable de negocio explica que nadie tendrá tiempo de hacer clic. En tres frases, una reunión sobre inteligencia artificial puede revelar el verdadero obstáculo para el cumplimiento normativo: los equipos utilizan las mismas palabras sin hablar de lo mismo. Con septiembre de 2026 en el horizonte, la aplicación progresiva del AI Act europeo convierte esta dificultad en un factor decisivo. Saber traducir una norma en una decisión operativa se convierte en una competencia colectiva, tan importante como la calidad del modelo.
Un calendario normativo, varios relojes internos
El reglamento europeo sobre inteligencia artificial, que entró en vigor el 1 de agosto de 2024, establece una aplicación por etapas. Las disposiciones sobre prácticas prohibidas y alfabetización en IA se aplican desde el 2 de febrero de 2025. El 2 de agosto de 2025 se alcanzó una nueva etapa, relativa, en particular, a los modelos de IA de uso general. En el calendario inicial del texto, el 2 de agosto de 2026 constituye el siguiente gran hito, mientras que determinadas obligaciones relativas a los sistemas de alto riesgo integrados en productos regulados están previstas para agosto de 2027.
Estas fechas no significan que todas las herramientas pasen a estar sujetas simultáneamente a las mismas obligaciones. Existen disposiciones transitorias, especialmente para determinados sistemas o modelos ya comercializados. Esta proyección hacia septiembre de 2026 se basa en el reglamento adoptado y en su calendario inicial: cualquier posible cambio posterior debe verificarse en los textos aplicables. La primera competencia útil es, por tanto, saber plantear la pregunta antes de anunciar un plazo.
Sin embargo, cada área tiene su propio reloj. El departamento jurídico piensa en términos de fechas de aplicación; los desarrolladores, de versiones; compras, de renovaciones contractuales; y las áreas de negocio, de objetivos trimestrales. Sin coordinación, cada uno puede cumplir su calendario y, al mismo tiempo, hacer que el proyecto incumpla el suyo.
Traducir los usos antes de traducir el derecho
Tomemos un caso ficticio: una empresa quiere utilizar un asistente para preparar la contratación de personal. «Solo sirve para ahorrar tiempo», asegura el área de negocio. Pero ¿qué hace exactamente? ¿Redacta una oferta, resume las candidaturas o clasifica a las personas que serán entrevistadas? Estos usos no plantean las mismas cuestiones. Determinados sistemas destinados a la contratación o la selección figuran entre las categorías de alto riesgo del reglamento, con sujeción a las condiciones y excepciones previstas.
Por tanto, el diálogo debe empezar por verbos, no por etiquetas comerciales. ¿Quién proporciona los datos? ¿Qué produce el sistema? ¿Quién consulta el resultado? ¿Qué decisión puede derivarse de él? Una demostración de un proceso completo suele ser más útil que una presentación que anuncia una solución «responsable». Permite al jurista comprender el uso real y al desarrollador ver las consecuencias de sus decisiones.
La clasificación de los actores exige la misma precisión. ¿La empresa es proveedora, responsable del despliegue o podría cambiar de función al modificar sustancialmente un sistema? Comprar una interfaz no permite, por sí solo, responder a esa pregunta. Un vocabulario compartido no elimina la complejidad jurídica; evita ocultarla tras simplificaciones.
Transformar una obligación en una decisión verificable
La traducción resulta útil cuando vincula una exigencia con una acción observable. «Garantizar la supervisión humana» sigue siendo abstracto. Determinar quién puede interrumpir el procesamiento, con qué información y con qué autoridad, ya constituye una decisión de diseño. Para los sistemas afectados, la supervisión no se limita a situar a una persona al final del proceso: también es necesario que pueda comprender, cuestionar y corregir.
En nuestro proceso de selección ficticio, el equipo podría examinar una propuesta: no permitir que una clasificación automática desencadene por sí sola un rechazo. Esta decisión no es una receta universal ni una garantía de cumplimiento normativo. Sin embargo, obliga a debatir sobre el tiempo disponible, el acceso a las candidaturas originales y el riesgo de que el responsable de selección siga mecánicamente la recomendación.
Un documento compartido puede resumirse en cinco líneas por tema:
- La exigencia: lo que pide el texto aplicable, con su fuente.
- El riesgo concreto: lo que podría ocurrirle a una persona o al proceso.
- La decisión: lo que el equipo desarrolla, limita o descarta.
- La prueba: el ensayo, el documento o el registro que permite verificar esa decisión.
- El responsable: la persona encargada de la acción y de su seguimiento.
Este esquema evita dos callejones sin salida: el informe jurídico que nadie sabe aplicar y la funcionalidad entregada sin un vínculo explícito con la obligación. También hace visibles los desacuerdos antes de que se conviertan en incidentes.
Organizar el desacuerdo en lugar de buscar un consenso débil
La reunión eficaz no es aquella en la que todo el mundo da su aprobación. Es aquella en la que las objeciones permiten actuar. El jurista debe poder distinguir entre una prohibición, una obligación sujeta a condiciones y una zona de incertidumbre. El desarrollador debe precisar qué es técnicamente posible, costoso o imposible de garantizar. El área de negocio debe reconocer cuándo su organización impide realizar un control que, sin embargo, está previsto en la interfaz.
La reformulación cruzada constituye un ejercicio sencillo: cada uno explica la limitación del otro antes de defender su solución. «Si lo entiendo bien, necesitan recuperar los elementos que condujeron a esta recomendación». O bien: «Su equipo no puede revisar cada expediente en el plazo actual». Esta disciplina revela los falsos acuerdos, sin exigir que cada uno se convierta en experto en el ámbito del otro.
Después hace falta una regla para resolver las discrepancias. ¿Quién decide reducir el alcance, aplazar el lanzamiento o aceptar un riesgo residual dentro de los límites legales? Conviene dejar una breve constancia de la decisión: opciones examinadas, motivos de la elección, reservas y condiciones de revisión. Así, el cumplimiento normativo adquiere memoria, en lugar de acumular una colección de validaciones dispersas.
Formar para que todos sean capaces de actuar
El artículo 4 del reglamento prevé medidas destinadas a garantizar un nivel suficiente de alfabetización en IA para el personal y otras personas implicadas, teniendo en cuenta, en particular, sus conocimientos, su experiencia y el contexto de uso. Esta lógica va más allá de una formación genérica idéntica para todos. Saber redactar una instrucción para un asistente no basta para comprender cuándo su resultado se vuelve peligroso o inadecuado.
Un responsable de compras debe saber qué información pedir al proveedor. Un responsable operativo debe reconocer una desviación en el uso. Un desarrollador debe comprender por qué determinadas pruebas deben reproducir las condiciones reales. Los talleres breves, organizados en torno a un incidente plausible, pueden ayudar a desarrollar estos reflejos: un resultado inventado, una recomendación cuestionada o un cambio de modelo por parte de un proveedor de servicios.
Así se pueden observar avances concretos sin fabricar un indicador mágico: ¿están mejor descritas las solicitudes? ¿Llegan las alertas antes del lanzamiento? ¿Saben los equipos a quién trasladar una duda? La calidad del diálogo se mide, sobre todo, por las decisiones que permite tomar.
¿Y ahora qué? A medida que avanza la aplicación del reglamento, las organizaciones podrían descubrir que su mejor inversión no es un comité adicional, sino unos cuantos hábitos sólidos: describir los usos, reformular las limitaciones, documentar las decisiones y revisarlas cuando cambie el sistema. Ahí está el reto de cara al futuro: convertir el cumplimiento normativo en una capacidad de adaptación compartida, en lugar de un control final cuyas conclusiones nadie comprende realmente.
