La política de IA es el documento más corto de un sistema ISO 42001 y el que más a menudo se escribe mal, porque la versión fácil es la política de seguridad de la información con los sustantivos cambiados. Esa versión se lee de forma plausible y responde a la norma equivocada: un sistema de gestión de la IA pide en el apartado 5.2 una política adecuada a aquello para lo que la empresa usa la IA, que dé el marco de los objetivos de IA, se comprometa con los requisitos aplicables y con la mejora del sistema, esté documentada, comunicada y disponible y, a diferencia de su prima de 27001, diga cómo se sitúa junto a las demás políticas de la organización. Tres controles del anexo A llevan las mismas tres ideas: A.2.2 pide la política, A.2.3 su alineación con las demás políticas, A.2.4 su revisión. Este artículo lee el apartado para una empresa de software, expone las diez secciones que lleva una política de IA de dos páginas, nombra los deberes del Reglamento de IA que la política tiene que mencionar y la única clasificación que no debe hacer, enumera lo que señala un auditor, y describe la página gratuita que redacta la política a partir de once respuestas en seis idiomas.

Lo que pide el apartado, y en qué se diferencia de la política de seguridad

Cuatro de las cosas que pide el apartado 5.2 tratan del contenido y tres del manejo, y el contenido es donde la política de IA se separa de la política de seguridad. Adecuada al propósito significa que la política nombra aquello para lo que la empresa usa realmente la IA, triaje de soporte o revisión de contratos o asistencia al código, y si construye los sistemas o usa los de otros, porque los deberes difieren. El marco de los objetivos significa que la política dice qué objetivos del apartado 6.2 fija, y un objetivo de IA trata del uso previsto, el impacto, la revisión humana, la procedencia de los datos, los incidentes y la alfabetización, y no de la confidencialidad y la disponibilidad. El compromiso con los requisitos aplicables es donde entra la regulación, ya que el Reglamento de IA impone a un proveedor y a un responsable del despliegue deberes que ninguna política de seguridad menciona. Y la alineación con las demás políticas es una sección propia: un sistema de IA sigue siendo un sistema de información bajo la política de seguridad, sus datos siguen siendo datos bajo la política de protección de datos, su proveedor sigue siendo un proveedor bajo la política de proveedores, y la política de IA tiene que decir qué pasa cuando parecen contradecirse. El manejo es el mismo que en 27001: documentada según el apartado 7.5 con un responsable, una versión y una aprobación, comunicada de modo que un recién llegado pueda decir qué le pide, y disponible para un cliente o un auditor a petición.

Las diez secciones de una política de IA breve

Propósito: para qué usa la empresa la IA hoy y quién es responsable, en un párrafo que nombra los usos. Alcance: qué sistemas, los construidos, comprados, integrados u operados, y qué personas. Posición: el puñado de frases que hacen de la política la propia de la empresa, que la IA se usa donde el trabajo mejora y su comportamiento puede explicarse, que cada sistema tiene un uso previsto declarado y un propietario con nombre, que un humano sigue pudiendo revisar y anular un resultado que afecta a una persona, que el impacto se evalúa antes de apoyarse en él y de nuevo al cambiar, que los datos personales se usan solo sobre una base lícita registrada, y que el contenido generado se marca y se comprueba. Los usos excluidos: las decisiones que la empresa no delegará en un sistema, escritas para que la decisión exista, por obvia que parezca. Responsabilidad: quién es titular de la política y la aprueba, quién gestiona el sistema a diario, y que cada sistema tiene un propietario en el inventario. Objetivos: de tres a cinco líneas medibles. Los requisitos aplicables: la sección de abajo. La relación con las demás políticas: junto a ellas, no en su lugar, con una vía para los conflictos. Comunicación y disponibilidad: incorporación, las medidas de alfabetización y disponibilidad a petición. Revisión: el ciclo y los tres desencadenantes, una capacidad sustancialmente nueva, una finalidad cambiada, una posición reguladora que se ha movido.

Los deberes del Reglamento de IA que la política nombra, y lo único que no debe decir

La sección de requisitos es breve y concreta. El deber de alfabetización en IA del artículo 4 vincula a todo proveedor y responsable del despliegue, así que la política compromete a la empresa a dar a toda persona que opera un sistema o se apoya en él los conocimientos que su función necesita, y remite al registro de alfabetización que lo demuestra. Cuando la empresa construye sistemas, se compromete con los deberes del proveedor tal como se aplican a la clasificación de cada sistema y con los compromisos que da a los clientes que los despliegan; cuando usa sistemas de otros, con los deberes del responsable del despliegue y con las instrucciones de uso del proveedor en el que se apoya. Cuando genera texto, imágenes o código, los deberes de transparencia del artículo 50 se aplican a lo que construye o usa. Cuando trata datos personales, se aplica el derecho de protección de datos, incluida la evaluación de impacto cuando el tratamiento pueda entrañar un alto riesgo. Y para cada sistema, la política se compromete a una determinación registrada de si es de alto riesgo según el Reglamento de IA, hecha sobre los hechos de ese sistema y conservada con su entrada del inventario. Lo que la política no debe hacer es esa determinación por sí misma: una frase que diga "nuestros sistemas no son de alto riesgo" es una conclusión jurídica sobre hechos que la política no conoce, y un auditor la lee exactamente así. La determinación de alto riesgo es una página propia, por sistema, y la evaluación de impacto sobre los derechos fundamentales sigue cuando la respuesta es sí.

Los errores que señala un auditor

La política de seguridad con los sustantivos cambiados, que no tiene posición sobre la IA, ni usos excluidos, ni inventario. "IA responsable" como adjetivos, sin objetivo que pueda medirse y sin nada en la revisión por la dirección que lo mida. Una clasificación en la política, de alto riesgo o no, afirmada para todos los sistemas a la vez. Ninguna vía para que una persona afectada por un resultado llegue a un humano que pueda anularlo, en una empresa cuyos sistemas afectan a personas. Silencio sobre la IA generativa en una empresa donde todos la usan. Ninguna frase sobre cómo se sitúa la política junto a las de seguridad, protección de datos y proveedores, de modo que el primer conflicto lo resuelve quien lo nota. Y los tres de siempre: sin aprobación, sin registro de comunicación, sin revisión desde la primera versión. Cada uno es un hallazgo en la primera auditoría, y cada uno se evita escribiendo las diez secciones y fechándolas.

Qué hacer con ello

Responda las once preguntas de la página gratuita: para qué usa la empresa la IA, si construye sistemas, usa los de otros o ambas cosas, si los resultados afectan a decisiones sobre personas, si los sistemas tratan datos personales, si usa IA generativa, los usos que excluye, quién gestiona el sistema, quién aprueba la política, el ciclo de revisión y los objetivos que medirá. La página redacta las diez secciones con palabras llanas, nombra los deberes del Reglamento de IA que las respuestas requieren y la determinación que cada sistema aún necesita, y dice cómo se sitúa la política junto a las demás. Edítela hasta que suene como la empresa, haga que el aprobador la firme y la feche, publíquela donde todo recién llegado la lea, y empiece el inventario y las evaluaciones de impacto que promete. StandardOS redacta la política de IA y las políticas de evaluación de impacto, gobernanza de datos y proveedores que dependen de ella a partir de las mismas respuestas, con versiones, y convierte el inventario, las evaluaciones y los registros de alfabetización en filas y fechas; los controles del anexo A dicen, con las palabras de StandardOS, qué pide cada uno de los tres controles sobre la política.