IEEE 2863: siete decisiones que le tocan al órgano de gobierno de la IA

El IEEE publicó el 16 de octubre su práctica recomendada sobre gobierno de la IA en las organizaciones, IEEE 2863-2026. Se descarga sin coste con una cuenta gratuita, dentro de su programa GET, y la he leído entera porque me interesa su punto de partida: separa el gobierno de la gestión y se queda con lo primero. Cómo se ejecuta cada cosa en cada sistema lo deja expresamente fuera de su alcance (apartado 4.3).

Por eso, desde mi punto de vista, se aprovecha mejor como lista de decisiones que alguien tiene que haber tomado en tu organización. Yo he sacado siete, y las cuento más abajo con el apartado de donde salen.

Qué es y qué no pretende ser

Es una práctica recomendada, así que recomienda. La propia norma avisa en su apartado 4.8 de que seguirla no constituye cumplimiento legal y de que sus disposiciones solo complementan lo que exija cada jurisdicción. Tampoco da presunción de conformidad con el AI Act: el artículo 40 la reserva a las normas armonizadas citadas en el Diario Oficial, y hoy la única que me consta es EN 18286.

Con ISO/IEC 42001 se lleva bien. La 42001 es un sistema de gestión, e IEEE 2863 remite a ella para el ciclo de mejora continua. Yo las leo como dos preguntas distintas: la 42001 pregunta cómo sostiene la organización lo que hace, y la 2863 pregunta quién lo ha decidido.

Ese «quién» es lo que la norma llama órgano de gobierno. Tiene que estar formado por personas y reunir experiencia de varias disciplinas, y puede delegar parte de la supervisión en un comité o en personal dedicado siempre que conserve la supervisión del conjunto. Dónde se coloca dentro de cada casa es otra conversación, que ya he tratado en dónde colgar la función de gobierno de IA.

Las siete decisiones

1. Qué principios priman en cada sistema

Dos valen siempre: no hacer daño y proteger los derechos humanos. Otros quince, agrupados en valores humanos, valores sociales, fiabilidad y responsabilidad, los prioriza el órgano sistema a sistema, a partir de una evaluación inicial de riesgos (apartados 4.9 y 5). Un sistema que decide sobre personas y otro que resume documentos internos no tienen por qué priorizar lo mismo, y la norma pide que esa elección exista y quede escrita.

2. Desde qué momento una iniciativa entra en gobierno

El apartado 6.1.5 pide al órgano que defina o apruebe un umbral, y da ejemplos: cuando se asigna un código de proyecto, cuando se aprueba un presupuesto o un caso de negocio, o cuando un cliente pide una funcionalidad concreta. Me parece de lo más útil del documento. He escrito sobre las puertas reales que cruza una IA, y este umbral es la primera de ellas: si no está definido, cada proyecto decide por su cuenta cuándo le toca pasar por gobierno.

3. Qué hace falta para autorizar un despliegue

La norma trata la decisión de desplegar como un punto de control crítico (6.1.7). Ahí el órgano determina si hace falta una evaluación externa o una revisión independiente, comprueba que existen la documentación y los registros, y deja delimitadas las responsabilidades de cada función antes de que el sistema salga. Si tu desarrollo es iterativo, la misma norma admite que no todo sean hitos discretos, pero la decisión sigue teniendo que estar en algún sitio.

4. Cuánto pesa el asesoramiento ético

El apartado 6.3.4 pide especificar a quién van dirigidas las recomendaciones del comité o del asesor de ética y qué peso tienen: vinculantes o consultivas. También pide hacer pública su existencia, su composición y su nivel de actividad. Desde mi experiencia, cuando nadie ha decidido el peso, la recomendación acaba siendo consultiva por defecto, y por eso prefiero que se escriba al diseñar el comité.

5. Qué incidentes suben hasta el órgano

El apartado 6.4.4 pide definir qué incidentes se comunican de inmediato al órgano, establecer un informe periódico que incluya los casi incidentes y revisar el plan de respuesta con pruebas de estrés o simulacros. El AI Act solo obliga a notificar los incidentes graves, así que subir los casi incidentes es una decisión propia de la casa, y es la misma que proponía en el riesgo sistémico de los agentes. También ayuda a que el informe de gobierno diga algo más que cero incidentes.

6. Qué se audita y qué se cuenta

El apartado 6.2 ordena la auditoría con cuatro preguntas (quién, para qué, sobre qué y cuándo), y pide independencia respecto del equipo que desarrolló u opera el sistema. Lo que más me interesa es lo que viene después: los resultados llegan al órgano, y es él quien decide qué se hace público. La norma reconoce que publicar da garantías a terceros y que mantener el resultado interno puede favorecer la franqueza, de modo que deja la elección a cada organización.

7. Qué procesos adicionales se aplican a cada sistema

Además de la supervisión del ciclo de vida, la norma describe siete procesos: auditoría, supervisión ética, respuesta a incidentes, cadena de valor, partes interesadas, propiedad intelectual y red teaming. No todos valen para todo, y el órgano los elige según el riesgo, la escala y las preocupaciones de las partes afectadas. Si elige red teaming, la norma recomienda que el equipo sea independiente de quienes construyen y gestionan el sistema, y que informe directamente al órgano (6.8.3). Es una decisión de organización que conviene tomar antes del primer ejercicio.

Cuando dos principios chocan

Los seis casos del anexo A son la parte que más se presta a discusión, porque señalan qué principios se refuerzan y cuáles entran en tensión. En el de la recuperación automatizada de prestaciones sociales, la eficacia choca con el bienestar y con la supervisión humana, que introduce demoras. En el de la IA generativa, una organización puede ganar eficacia sin contar que la usa, y ahí choca con la transparencia.

La norma no da una tabla de pesos. Dice que no existe un único orden de prioridades válido para todos y que cada órgano tiene que identificar sus dilemas, diseñar cómo resolverlos y documentar lo que decide. En el primer caso llega a reconocer que algunas situaciones son dilemas morales que ningún proceso resuelve, y me parece una forma honesta de plantearlo. Para una organización, lo práctico es que la tensión aparezca escrita junto a la decisión, con lo que se ha priorizado y lo que se ha aceptado a cambio.

Si tu organización compra IA en lugar de desarrollarla

La norma pide las cinco fases del ciclo de vida a quien desarrolla, y a quien usa, la operación y la retirada. A quien compra le añade el proceso de cadena de valor, que le pide identificar a sus proveedores y validar lo adquirido para el uso concreto que le va a dar (6.5.4). Y el caso de la IA generativa está escrito precisamente para quien usa estas herramientas.

Yo añadiría una cosa, que el caso del reconocimiento facial también le pide al usuario: hacer la evaluación inicial antes de comprar. Desde mi experiencia, buena parte del riesgo de un sistema comprado se decide antes de firmar, y externalizar la IA no externaliza el riesgo.

Qué haría con esto

No adoptaría la norma entera de golpe, y ella misma no lo pide: si la organización tiene poca actividad de IA, el órgano decide primero qué partes adopta (4.9).

Haría una hoja con siete filas, una por decisión, con cuatro columnas: qué se ha decidido, quién lo ha decidido, cuándo y qué obliga a revisarlo. Después la llevaría al órgano de gobierno. Las filas vacías dicen más que las llenas, porque una decisión sin escribir se está tomando igual, proyecto a proyecto, por quien tenga más prisa. Y cada fila llena necesita un dueño con nombre, que es lo que convierte una recomendación de un documento de ochenta páginas en algo que alguien responde en tu casa.