Gobernanza de IA: marcos, programas y carreras.

El Reglamento Europeo de IA (AI Act), Reglamento (UE) 2024/1689, es la primera ley horizontal integral sobre inteligencia artificial. Alcanza a organizaciones dentro y fuera de la Unión Europea cuando introducen sistemas de IA en el mercado europeo o cuando la salida de sus sistemas se usa en la UE, lo que incluye a muchas empresas latinoamericanas. Sus obligaciones se aplican por etapas, y el calendario de algunas de ellas, sobre todo para los sistemas de alto riesgo, se modificó en 2026 mediante un paquete de cambios puntuales conocido como Digital Omnibus. Como esas fechas cambiaron, esta guía no las repite: consulte siempre el texto consolidado más reciente en EUR-Lex antes de planificar en función de un plazo.

La UE no está sola. Las autoridades de protección de datos ya aplican el RGPD y la LGPD de Brasil a la IA, varios estados de Estados Unidos aprueban leyes específicas y Brasil debate un proyecto de ley propio sobre IA. La dirección común es clara: obligaciones proporcionales al riesgo, transparencia hacia las personas afectadas, supervisión humana y rendición de cuentas documentada.

Los reguladores son solo una de las audiencias. Los clientes corporativos hacen cada vez más preguntas detalladas sobre IA antes de firmar: qué modelos se usan, a dónde van los datos, si los datos del cliente se usan para entrenar modelos, cómo se prueban las salidas y a quién se avisa cuando algo sale mal. El proveedor que responde con evidencias cierra negocios; el que responde con una página de marketing los pierde o acepta cláusulas desfavorables.

Antes de la IA generativa, la mayoría de las organizaciones tenía unos pocos modelos construidos por especialistas. Hoy casi cualquier colaborador puede usar un chatbot, un asistente de código o una función de IA integrada en el software de oficina. Eso lleva el riesgo de IA del equipo de ciencia de datos a toda la organización: datos confidenciales pegados en prompts, hechos alucinados en documentos para clientes, dudas de derechos de autor sobre el contenido generado y nuevas superficies de ataque, como la inyección de prompts. La gobernanza tiene que llegar a quienes nunca entrenarán un modelo, y por eso la alfabetización en IA se volvió un control de gobernanza en sí misma.

El reglamento no regula la "IA" como tecnología. Regula usos y gradúa las obligaciones según el riesgo que cada uso genera para la salud, la seguridad y los derechos fundamentales. El resultado suele describirse como cuatro niveles, más un régimen aparte para los modelos de uso general:

El nivel depende de la finalidad prevista, no del modelo: el mismo modelo de lenguaje puede estar en un asistente de redacción de riesgo mínimo y en un filtro de candidatos de alto riesgo. Por eso un inventario de IA con clasificación de riesgo por caso de uso es la base del cumplimiento.

Las obligaciones dependen del rol, así que la primera pregunta jurídica sobre cualquier sistema es "¿cuál es nuestro rol?". El reglamento define varios operadores:

• Proveedor (provider): desarrolla un sistema de IA o un modelo de uso general, o lo manda desarrollar, y lo introduce en el mercado o lo pone en servicio con su propio nombre o marca. Asume la mayor parte de las obligaciones de alto riesgo. Vea proveedor.
• Responsable del despliegue (deployer): usa un sistema de IA bajo su autoridad en una actividad profesional. Un banco que usa un modelo de crédito de terceros es responsable del despliegue. Vea responsable del despliegue.
• Importador y distribuidor: traen sistemas de fuera de la UE o los comercializan, con deberes de verificación.
• Representante autorizado: persona establecida en la UE designada por un proveedor de fuera de la UE.
• Fabricante del producto: introduce en el mercado un producto regulado que lleva un sistema de IA como componente de seguridad.

Los roles pueden cambiar. Un responsable del despliegue que pone su nombre en un sistema de alto riesgo, le hace una modificación sustancial o cambia la finalidad de un sistema de modo que pase a ser de alto riesgo puede ser tratado como proveedor, con todas las obligaciones correspondientes. Las áreas de compras y de producto deben saberlo antes de personalizar la herramienta de un proveedor para un uso sensible.

El artículo 5 enumera las prácticas de IA prohibidas, porque su riesgo para los derechos fundamentales se considera inaceptable. En resumen, prohíbe los sistemas de IA que:

• usen técnicas subliminales, manipuladoras o engañosas que alteren de manera sustancial el comportamiento y causen, o puedan causar, un daño significativo;
• exploten vulnerabilidades ligadas a la edad, la discapacidad o una situación social o económica específica, con el mismo efecto;
• evalúen o clasifiquen a las personas según su comportamiento social o sus características personales de forma que generen un trato perjudicial injustificado o desproporcionado (puntuación social);
• evalúen el riesgo de que una persona cometa un delito basándose únicamente en la elaboración de perfiles o en rasgos de personalidad;
• creen o amplíen bases de datos de reconocimiento facial mediante la extracción no selectiva de imágenes de internet o de circuitos cerrados de televisión;
• infieran emociones en el lugar de trabajo o en instituciones educativas, salvo por razones médicas o de seguridad;
• categoricen a las personas por datos biométricos para inferir atributos sensibles, como raza, opiniones políticas, afiliación sindical, creencias religiosas u orientación sexual, con excepciones limitadas;
• realicen identificación biométrica remota en tiempo real en espacios de acceso público con fines de aplicación de la ley, salvo en situaciones estrictamente definidas y autorizadas.

Un sistema es de alto riesgo en dos situaciones: cuando es componente de seguridad de un producto, o el propio producto, cubierto por la legislación de armonización de la UE listada en el Anexo I (máquinas, productos sanitarios, juguetes, vehículos y otros) que exige evaluación de la conformidad por un tercero; o cuando encaja en una de las áreas de uso del Anexo III. Esas áreas son biometría, infraestructura crítica, educación y formación profesional, empleo y gestión de trabajadores, acceso a servicios esenciales públicos y privados (incluida la evaluación crediticia y ciertos seguros), aplicación de la ley, migración y control fronterizo, y administración de justicia y procesos democráticos.

Un sistema del Anexo III puede quedar fuera de la etiqueta de alto riesgo si no plantea un riesgo significativo, por ejemplo porque solo realiza una tarea procedimental limitada o mejora el resultado de una actividad humana ya concluida. El proveedor debe documentar esa evaluación, y los sistemas que elaboran perfiles de personas físicas siguen siendo de alto riesgo. Los proveedores de sistemas de alto riesgo deben, entre otras cosas:

• mantener un sistema de gestión de riesgos durante todo el ciclo de vida (artículo 9);
• aplicar gobernanza a los datos de entrenamiento, validación y prueba, incluido el examen de posibles sesgos (artículo 10);
• elaborar documentación técnica (artículo 11 y Anexo IV) y permitir el registro automático de eventos (artículo 12);
• entregar instrucciones de uso claras a los responsables del despliegue (artículo 13);
• diseñar el sistema para una supervisión humana efectiva (artículo 14);
• lograr niveles adecuados de precisión, solidez y ciberseguridad (artículo 15);
• operar un sistema de gestión de la calidad (artículo 17);
• completar la evaluación de la conformidad, emitir la declaración UE de conformidad, colocar el marcado CE y registrar el sistema en la base de datos de la UE;
• hacer seguimiento del sistema después de introducirlo en el mercado y notificar los incidentes graves.

Los responsables del despliegue tienen una lista más corta, pero real (artículo 26): usar el sistema según sus instrucciones, asignar la supervisión humana a personas con la competencia, la formación y la autoridad necesarias, asegurar que los datos de entrada bajo su control sean pertinentes, supervisar el funcionamiento y comunicar riesgos, conservar los registros bajo su control, informar a los trabajadores y a sus representantes antes de usar IA de alto riesgo en el trabajo e informar a las personas cuando un sistema de alto riesgo toma o apoya decisiones sobre ellas. Los organismos públicos, las entidades privadas que prestan servicios públicos y los responsables del despliegue de ciertos sistemas de crédito y seguros también deben realizar una evaluación de impacto en los derechos fundamentales (artículo 27). Las personas afectadas obtienen el derecho a una explicación de ciertas decisiones (artículo 86).

El capítulo V regula los modelos de IA de uso general: modelos entrenados con grandes volúmenes de datos, capaces de realizar con competencia una amplia gama de tareas y de integrarse en muchos sistemas. Sus proveedores deben mantener documentación técnica, dar a los proveedores posteriores la información que necesitan para entender el modelo y cumplir sus propias obligaciones, adoptar una política de cumplimiento de los derechos de autor de la UE y publicar un resumen suficientemente detallado del contenido usado para el entrenamiento, según una plantilla de la Oficina de IA.

Los modelos clasificados como de riesgo sistémico, condición que se presume por encima de un umbral de cómputo de entrenamiento que la Comisión puede actualizar, tienen deberes adicionales: evaluación del modelo según el estado de la técnica, incluidas pruebas adversarias (red teaming), evaluación y mitigación de riesgos sistémicos, notificación de incidentes graves y ciberseguridad adecuada. Un Código de Buenas Prácticas voluntario para la IA de uso general ofrece una vía para demostrar el cumplimiento. Para quien usa estos modelos sin construirlos, la consecuencia está más abajo en la cadena: pida la documentación que los proveedores ahora están obligados a entregar.

El artículo 50 aplica en cualquier nivel de riesgo. Los proveedores deben diseñar los sistemas que interactúan con personas de modo que estas sepan que tratan con una IA, salvo que sea evidente por el contexto, y deben marcar el audio, la imagen, el video y el texto sintéticos de forma legible por máquina. Los responsables del despliegue de sistemas de reconocimiento de emociones o de categorización biométrica deben informar a las personas expuestas. Quien genera o manipula ultrasuplantaciones debe revelar que el contenido es artificial, y el texto generado por IA que se publica para informar al público sobre asuntos de interés público debe identificarse, salvo que haya pasado por revisión humana y alguien asuma la responsabilidad editorial.

El artículo 4 pide a proveedores y responsables del despliegue que adopten medidas para garantizar, en la mayor medida posible, un nivel suficiente de alfabetización en IA de su personal y de otras personas que operan sistemas de IA en su nombre, considerando sus conocimientos técnicos, experiencia, educación y formación, y el contexto de uso. Como el reglamento se modificó en 2026, verifique la redacción vigente de este artículo en el texto consolidado. En cualquier caso, la lógica de gobernanza no cambia: nadie supervisa, cuestiona ni usa con seguridad un sistema que no entiende.

El reglamento no exige ningún certificado en particular. Lo que la organización necesita es evidencia de que la formación es proporcional a los roles y los riesgos: quién fue formado, en qué, cuándo y cómo se verificó la comprensión. Vea la sección sobre alfabetización en IA más abajo.

La supervisión es compartida. La Oficina de IA, dentro de la Comisión Europea, supervisa los modelos de uso general; las autoridades nacionales de vigilancia del mercado supervisan los sistemas de IA, con la coordinación del Comité Europeo de Inteligencia Artificial. Algunos países crearon organismos específicos, como la AESIA (Agencia Española de Supervisión de la Inteligencia Artificial), y los Estados miembros deben ofrecer espacios controlados de pruebas (sandboxes) para la IA.

Las sanciones son escalonadas. Las multas más altas, por prácticas prohibidas, pueden llegar a 35 millones de euros o al 7% del volumen de negocios anual mundial, lo que sea mayor, con topes menores para otras infracciones y un trato proporcional para las pymes. La aplicación es por etapas: las prohibiciones, la alfabetización en IA y las reglas de modelos de uso general comenzaron antes que la mayoría de las obligaciones de alto riesgo, y el calendario de alto riesgo se pospuso con las modificaciones de 2026. Consulte en EUR-Lex el texto consolidado más reciente para conocer las fechas que le aplican.

Un sistema de gestión de IA aplica a la IA el conocido ciclo planificar, hacer, verificar y actuar. La ISO/IEC 42001 usa la estructura armonizada común a la ISO 27001, la ISO 9001 y otras normas de sistemas de gestión, así que quien ya opera una de ellas puede integrar el AIMS en lugar de empezar desde cero. Sus cláusulas principales le piden:

• entender el contexto de la organización, su rol respecto de la IA (desarrolladora, proveedora, usuaria, etcétera) y las necesidades de las partes interesadas, y definir el alcance del AIMS (cláusula 4);
• asegurar el compromiso de la dirección, una política de IA y roles y responsabilidades claros (cláusula 5);
• planificar acciones para riesgos y oportunidades, incluida la evaluación de riesgos de IA, el tratamiento de riesgos de IA y la evaluación de impacto del sistema de IA, y fijar objetivos de IA (cláusula 6);
• proveer recursos, competencia, toma de conciencia, comunicación e información documentada (cláusula 7);
• operar los procesos y controles planificados (cláusula 8);
• hacer seguimiento, medir, auditar internamente y realizar revisiones por la dirección (cláusula 9);
• corregir las no conformidades y mejorar continuamente (cláusula 10).

El Anexo A enumera objetivos de control y controles de referencia agrupados en temas: políticas relacionadas con la IA; organización interna; recursos para los sistemas de IA; evaluación de los impactos de los sistemas de IA; ciclo de vida del sistema de IA; datos para los sistemas de IA; información para las partes interesadas; uso de los sistemas de IA; y relaciones con terceros y clientes. El Anexo B da orientación de implementación para cada control, el Anexo C enumera posibles objetivos y fuentes de riesgo relacionados con la IA y el Anexo D trata del uso en distintos dominios y sectores.

Como en la ISO 27001, no se aplican todos los controles a ciegas. El tratamiento de riesgos determina qué controles son necesarios, y el resultado se registra en la Declaración de Aplicabilidad (SoA): cada control del Anexo A, si se incluye, por qué y si está implementado, además de los controles adicionales que haya agregado. Los auditores leen la SoA como el puente entre sus riesgos y sus controles, así que debe poder rastrearse hasta la evaluación de riesgos, y no ser una copia del anexo con "sí" en todas las filas.

Esta distinción genera mucha confusión. La certificación ISO/IEC 42001 se otorga al sistema de gestión de una organización por medio de un organismo de certificación, idealmente acreditado para ese esquema; la ISO/IEC 42006 fija requisitos para los organismos que auditan y certifican sistemas de gestión de IA. El certificado dice que el AIMS de la organización, dentro de un alcance definido, es conforme con la norma.

La certificación de personas es otra cosa: acredita que una persona demostró conocimientos o competencias especificados, por lo general mediante un examen. DPCert certifica personas. Nuestros exámenes cubren la ISO/IEC 42001 junto con el Reglamento Europeo de IA, el NIST AI RMF y la legislación de protección de datos, y nuestro esquema está diseñado con referencia a la ISO/IEC 17024, la norma para organismos que certifican personas. Una credencial de DPCert no es un certificado ISO ni certifica a ninguna organización; es evidencia de lo que sabe su titular.

• ISO/IEC 22989: conceptos y terminología de IA, útil para alinear el vocabulario entre las áreas jurídica, de riesgos y de ingeniería.
• ISO/IEC 23894: orientación sobre gestión de riesgos de IA, que adapta la ISO 31000 a la IA.
• ISO/IEC 42005: orientación para la evaluación de impacto de sistemas de IA.
• ISO/IEC 42006: requisitos para organismos que auditan y certifican sistemas de gestión de IA.

Las normas europeas armonizadas que respaldan el Reglamento Europeo de IA las elaboran por separado el CEN y el CENELEC. Cuando se publiquen y se citen en el Diario Oficial, seguirlas otorgará presunción de conformidad con los requisitos correspondientes; la ISO/IEC 42001 por sí sola no la otorga.

En julio de 2024 el NIST publicó el NIST AI 600-1, el Perfil de IA Generativa. Identifica riesgos exclusivos o amplificados por la IA generativa, entre ellos la confabulación (el término del NIST para la alucinación), la integridad de la información, la seguridad de la información, la privacidad de los datos, el sesgo dañino y la homogeneización, la propiedad intelectual, el contenido peligroso o de odio, la configuración humano-IA, la cadena de valor y la integración de componentes, y los impactos ambientales. Para cada uno sugiere acciones vinculadas a las cuatro funciones. Si su principal exposición son colaboradores y productos que usan grandes modelos de lenguaje, este perfil es un buen punto de partida.

Según el artículo 35 del RGPD, una evaluación de impacto relativa a la protección de datos (EIPD) es obligatoria cuando es probable que el tratamiento entrañe un alto riesgo para los derechos y libertades de las personas, y el uso de nuevas tecnologías, la evaluación sistemática de aspectos personales y el tratamiento a gran escala de datos sensibles son detonantes típicos. Muchos proyectos de IA los cumplen. En Brasil, la LGPD prevé el informe de impacto a la protección de datos (RIPD), que la ANPD puede exigir. Con el Reglamento Europeo de IA, ciertos responsables del despliegue también deben hacer una evaluación de impacto en los derechos fundamentales. Las tres se superponen mucho; un buen programa las lleva como una evaluación coordinada, con evidencias compartidas.

El artículo 22 del RGPD otorga a las personas el derecho a no ser objeto de una decisión basada únicamente en el tratamiento automatizado, incluida la elaboración de perfiles, que produzca efectos jurídicos o les afecte significativamente de modo similar, con excepciones acompañadas de salvaguardas como la intervención humana y el derecho a impugnar; los artículos 13 a 15 exigen información significativa sobre la lógica aplicada. El artículo 20 de la LGPD otorga al titular el derecho a solicitar la revisión de decisiones tomadas únicamente con base en tratamiento automatizado que afecten sus intereses, y a obtener información sobre los criterios y procedimientos usados. Estas reglas moldean el diseño de las decisiones automatizadas: dónde interviene la persona, qué puede cambiar realmente y qué explicación recibe el afectado.

Entrenar o ajustar modelos con datos personales plantea preguntas que el área de privacidad debe responder temprano: qué base jurídica aplica (a menudo el interés legítimo, que exige una ponderación documentada), si la finalidad original de la recolección es compatible con el entrenamiento, cómo se informa a los interesados, cómo se aplican la minimización de datos y la conservación, y cómo funcionan derechos como el acceso, la oposición y la supresión cuando el dato está incorporado en un modelo. El Comité Europeo de Protección de Datos (CEPD) abordó varias de estas preguntas en su Dictamen 28/2024 sobre modelos de IA, incluido cuándo un modelo puede considerarse anónimo y las consecuencias de un tratamiento ilícito durante el desarrollo.

Para quien solo usa IA de terceros, las mismas preguntas pasan al contrato: si el proveedor usa sus datos para entrenar modelos, dónde se tratan los datos, qué subencargados participan y cómo se cubren las transferencias internacionales. Estas cláusulas ya son parte habitual de la contratación de IA.

Empiece con un estatuto breve aprobado por la alta dirección: por qué existe el programa, su alcance (qué entidades, qué tipos de IA), quién es el responsable y cómo reporta al directorio. Designe a un ejecutivo responsable y a un líder del programa, y decida si necesita un comité multidisciplinario de IA. Redacte una matriz RACI sencilla que cubra las áreas jurídica, de privacidad (incluido el delegado de protección de datos), seguridad, riesgos, ciencia de datos, ingeniería, compras, recursos humanos y los dueños de negocio de cada caso de uso. Muchas organizaciones lo alinean con el modelo de las tres líneas: dueños de negocio en la primera línea, riesgos y cumplimiento en la segunda, auditoría interna en la tercera.

No se puede gobernar lo que no se ve. Arme un inventario de IA que registre, para cada sistema o caso de uso: finalidad, responsable, usuarios y personas afectadas, modelo y proveedor, datos usados, decisiones en las que influye, su rol jurídico (proveedor o responsable del despliegue; responsable o encargado del tratamiento), la clasificación de riesgo y el estado de las evaluaciones exigidas. Incluya las funciones de IA dentro de herramientas SaaS y el uso de servicios públicos de IA generativa por parte de los colaboradores, y no solo los modelos internos. Asigne a cada registro un responsable y una fecha de revisión para que el inventario siga al día.

Defina un esquema que vincule cada caso de uso con un nivel de riesgo y con la revisión que necesita. Combine detonantes legales (niveles del Reglamento Europeo de IA, decisiones automatizadas del RGPD y la LGPD, reglas sectoriales) con criterios propios (impacto en las personas, escala, autonomía, reversibilidad, exposición reputacional). Manténgalo lo bastante corto para que un dueño de negocio lo complete en quince minutos. El resultado define el camino: los usos de bajo riesgo pasan por una revisión ligera, los de alto riesgo reciben una evaluación de impacto completa, un plan de pruebas y una aprobación formal, y los usos prohibidos se detienen.

Un conjunto pequeño de políticas cubre la mayoría de las necesidades:

• una política de IA que declare principios, alcance, roles y el proceso de revisión;
• una política de uso aceptable para colaboradores que usan IA generativa, que diga qué herramientas están aprobadas, qué datos nunca se pueden ingresar y cómo deben verificarse las salidas;
• un estándar de contratación de IA, con preguntas de debida diligencia y cláusulas contractuales;
• un estándar de desarrollo de modelos y sistemas, con documentación como las fichas de modelo, pruebas y criterios de liberación;
• un procedimiento de incidentes de IA vinculado a los procesos existentes de incidentes de seguridad y de privacidad.

Establezca un punto de control antes del despliegue, proporcional al riesgo. En los casos de alto riesgo, debe exigir una evaluación de impacto (que combine privacidad, derechos fundamentales y riesgos propios de la IA), un plan de pruebas con resultados frente a umbrales acordados, un diseño de supervisión humana, un plan de transparencia para las personas afectadas y una aprobación con nombre y apellido. Registre la decisión y sus condiciones. El punto de control también debe aplicar a cambios relevantes, como una nueva versión del modelo, una nueva fuente de datos o una nueva finalidad.

Después del despliegue, monitoree el desempeño, la deriva, los reclamos y las correcciones hechas por personas. La deriva del modelo y los cambios en la población atendida pueden convertir en silencio un sistema bien probado en uno dañino. Presente a la dirección métricas sencillas del programa (inventario clasificado, evaluaciones completadas, hallazgos abiertos, incidentes, cobertura de formación) y use un modelo de madurez para fijar metas anuales.

Una evaluación de impacto algorítmico pregunta quién puede verse afectado, cómo, con qué gravedad y con qué probabilidad, y qué se hará al respecto. Las buenas evaluaciones describen el sistema en lenguaje sencillo, identifican a los grupos afectados (incluidas las personas que nunca usan el sistema directamente), consideran el mal uso y los modos de falla, y terminan con mitigaciones concretas, cada una con un responsable. Son documentos vivos, que se revisan cuando cambia el sistema o su contexto.

Las pruebas deben planificarse a partir de los riesgos identificados, no aplicarse como una lista genérica. Para el sesgo algorítmico, elija métricas de equidad adecuadas a la decisión y al contexto jurídico y pruebe entre los grupos relevantes, sabiendo que distintas métricas pueden entrar en conflicto. Para la seguridad, incluya amenazas propias de la IA, como el envenenamiento de datos, la extracción de modelos y la inyección de prompts. En los sistemas generativos, el red teaming hecho por personas que intentan que el sistema falle es esencial y debe repetirse cuando cambian los modelos.

La supervisión humana es fácil de declarar y difícil de volver real. Un revisor que ve cientos de recomendaciones por hora, sin información ni autoridad para discrepar, no es supervisión; es sesgo de automatización con firma. La supervisión eficaz define qué verifica la persona, le da el contexto y la explicabilidad que necesita, le da tiempo y autoridad para revertir decisiones y mide con qué frecuencia lo hace. Si nadie revierte nunca nada, investigue.

Defina qué cuenta como incidente de IA (salida dañina, patrón discriminatorio, vulneración de seguridad, falla grave, mal uso) y gestiónelo con un proceso de triaje, contención, análisis de causa raíz, notificación cuando corresponda y lecciones aprendidas. Conéctelo con los procesos existentes: una inyección de prompts que filtra datos personales es a la vez un incidente de seguridad, una brecha de datos personales y un incidente de IA. Con el Reglamento Europeo de IA, los proveedores de sistemas de alto riesgo tienen deberes de notificar incidentes graves, y los responsables del despliegue deben informar a proveedores y autoridades en situaciones definidas.