Política de uso de IA: qué debe decir, con ejemplo [2026]
Una política de uso de inteligencia artificial es el documento que le dice a tu equipo qué herramientas puede usar, qué información no puede introducir en ellas, qué salidas tiene que revisar antes de que salgan y qué pasa si se incumple. No es una declaración de principios: es una regla de trabajo, y se distingue de un manifiesto en que se puede verificar si alguien la cumplió o no.
Esta guía es sobre el documento, no sobre el tema. Los 12 apartados que necesita, tres cláusulas redactadas como ejemplo, la tabla de revisión humana, cómo se aprueba, se comunica y se versiona, y los ocho errores de redacción que la convierten en papel. Si lo que buscas es quién decide y con qué órganos, eso está en la guía de gobernanza de IA; si buscas la norma certificable, en la guía de ISO 42001.
Contenido de esta guía
- Para qué sirve, y qué no resuelve
- Cuatro decisiones que se toman antes de redactar
- Los 12 apartados de una política auditable
- La regla que más se incumple: qué no entra en un chat
- La lista de herramientas: aprobadas, condicionadas, prohibidas
- Revisión humana por tipo de salida
- Ejemplo resuelto: tres cláusulas redactadas
- Aprobación, comunicación, aceptación y versión
- 8 errores de redacción que la vuelven papel
- Cómo encaja con tu manual de políticas y con ISO 42001
- Preguntas frecuentes
- Conclusión
Para qué sirve, y qué no resuelve
La política resuelve cuatro cosas concretas, y conviene tenerlas presentes porque determinan cómo se redacta cada apartado:
- Da una respuesta uniforme a una pregunta que hoy cada quien responde por su cuenta: «¿puedo pegar esto en una herramienta de IA?».
- Hace exigible una conducta. Sin regla escrita, comunicada y aceptada, no hay incumplimiento que se pueda sostener; hay una discusión de criterio.
- Sirve de evidencia hacia fuera. Es lo primero que piden los cuestionarios de proveedor y las auditorías de cliente.
- Baja el ruido interno. El equipo deja de preguntar caso por caso porque la regla está escrita y con ejemplos.
Y lo que no resuelve, por mucho que se redacte bien: no descubre qué IA se usa hoy —eso lo hace el inventario—, no evita que la información salga si no hay alternativa aprobada, no sustituye a la formación y no reemplaza a los contratos con los proveedores. Una política publicada sobre una empresa cuyo uso real nadie ha mirado regula a una empresa imaginaria. El inventario va antes que el documento.
"La prueba de una política de IA es simple: dásela a alguien de comercial y pídele que decida, con ella en la mano, si puede pegar el contrato de un cliente en un chat para resumirlo. Si tiene que preguntar, la política no está terminada."
¿Tu empresa gobierna la IA o solo la prohíbe?
En menos de 7 minutos mides tu madurez de IA segura y qué falta para gobernarla según ISO/IEC 42001.
Medir mi madurez de IALo escribe tu equipo con nuestras plantillas y nuestra revisión. Te contestamos en menos de 24 horas hábiles.
Cuatro decisiones que se toman antes de redactar
Redactar sin estas cuatro decidido produce un texto lleno de «se recomienda» y «en la medida de lo posible», que es la señal inequívoca de que nadie decidió nada:
- Qué herramientas quedan aprobadas. Con nombre y con plan contratado. Si la respuesta es «ninguna todavía», eso también hay que escribirlo, junto con la fecha en que habrá una.
- Qué clasificación de información se usa. La política se apoya en ella: no se puede decir «no introduzcas información confidencial» si nadie sabe qué es confidencial en tu empresa. Si no existe clasificación, tres niveles bastan para empezar: pública, interna, restringida.
- Qué decisiones no se automatizan. La lista corta de lo prohibido la decide la dirección, no el redactor del documento.
- Quién responde. Quién aprueba la política, quién resuelve dudas de interpretación, quién autoriza excepciones y quién atiende un incidente. Cuatro nombres, o cuatro puestos.
Los 12 apartados de una política auditable
Doce apartados, entre dos y cuatro páginas. Más largo no se lee; más corto deja huecos que el equipo va a rellenar por su cuenta:
Índice de la política
- Objetivo. Qué busca la política, en tres líneas y en lenguaje de operación.
- Alcance. A quién aplica: empleados, becarios, contratistas, proveedores con acceso a sistemas. Si aplica a terceros, tiene que estar en su contrato.
- Definiciones. Las mínimas indispensables —sistema de IA, entrada, salida, IA generativa, dato de entrenamiento— para que nadie discuta el significado.
- Principios. Cortos y operativos. Aquí y solo aquí caben: supervisión humana, transparencia, protección de datos, no discriminación, responsabilidad.
- Herramientas aprobadas, condicionadas y prohibidas. Con su lista viva y quién la mantiene.
- Qué información puede y no puede introducirse. El corazón del documento, apoyado en la clasificación.
- Usos permitidos, usos que requieren aprobación y usos prohibidos. Por proceso, no por tecnología.
- Revisión humana y verificación. Qué salidas se revisan, quién, antes o después, y qué se registra.
- Etiquetado y transparencia. Cuándo se avisa de que hubo IA de por medio, hacia dentro y hacia fuera.
- Propiedad intelectual y confidencialidad. Qué se puede hacer con lo generado y qué se le exige al proveedor sobre lo que entra.
- Reporte de incidentes y canal de dudas. A dónde se avisa, en cuánto tiempo, y el compromiso de no represalia por reportar.
- Cumplimiento, excepciones y vigencia. Consecuencias del incumplimiento, cómo se pide una excepción y cuándo se revisa el documento.
Dos apartados son los que un auditor abre primero —el 6 y el 8— y son también los que peor se redactan. Los siguientes dos capítulos van sobre ellos.
La regla que más se incumple: qué no entra en un chat
Casi todas las políticas dicen «no se debe introducir información confidencial». Nadie sabe aplicarlo, porque quien está a las cuatro de la tarde intentando resumir un documento no tiene claro si eso es confidencial. La regla funciona cuando está escrita con ejemplos del trabajo real de la empresa, en positivo y en negativo.
Cómo se redacta esta regla para que se pueda aplicar
- Nunca, en ninguna herramienta: datos personales de empleados, candidatos o clientes —nombres con datos asociados, identificaciones oficiales, domicilios, información de salud, datos bancarios—; credenciales y llaves de acceso; información bajo acuerdo de confidencialidad de un cliente; código fuente propietario del producto.
- Solo en herramientas aprobadas y contratadas por la empresa: información interna no clasificada —procedimientos, documentos de trabajo, borradores—, datos agregados sin identificar a nadie, extractos de contratos con los nombres sustituidos.
- Sin restricción: información pública, contenido ya publicado por la empresa, material de formación general.
- Cuando haya duda: se anonimiza —quitar nombres, folios y cifras identificables— o se pregunta al responsable designado. La política dice a quién, con nombre de puesto.
Dos reglas complementarias que casi nunca se escriben y ahorran el 80 % de los incidentes: desactivar el uso de las entradas para entrenamiento en la configuración de las cuentas corporativas y dejarlo verificado en el contrato; y prohibir las cuentas personales para trabajo de la empresa, con la alternativa corporativa disponible antes de prohibir nada. Prohibir sin alternativa mueve el uso a la sombra, no lo elimina.
La lista de herramientas: aprobadas, condicionadas, prohibidas
La lista no va dentro del cuerpo de la política —cambiaría cada mes y obligaría a reaprobar el documento—: va como anexo vivo, con dueño y fecha de última revisión. Cada entrada necesita cinco datos:
- Herramienta y plan contratado —el plan importa: las condiciones de tratamiento de datos cambian entre el gratuito y el corporativo—.
- Para qué se aprueba, y para qué no.
- Qué nivel de información admite, según la clasificación del apartado 6.
- Quién la paga y quién da de alta a los usuarios.
- Fecha de revisión de sus condiciones contractuales.
La categoría intermedia —condicionada— es la que salva la lista de volverse irreal: herramientas que se pueden usar solo para un propósito, solo por un área o solo con información pública. Sin ella, todo acaba siendo prohibido en el papel y permitido en la práctica.
Y no olvides la IA que no compraste: la que viene incluida en la suite ofimática, en el CRM, en la herramienta de soporte o en el repositorio de código. Está en tu empresa, procesa tu información y casi nunca aparece en estas listas.
Revisión humana por tipo de salida
«Toda salida debe ser revisada por una persona» es una frase que garantiza que nada se revise. Lo que funciona es una tabla corta que diga, por tipo de salida, quién revisa, cuándo y qué queda registrado:
Tabla de revisión, con el criterio de cada nivel
- Texto interno de trabajo (resúmenes, borradores, notas): revisa quien lo usa, antes de reutilizarlo. Sin registro.
- Comunicación a cliente (correos, respuestas, propuestas): revisa el responsable de la cuenta, antes de enviar. Registro: el envío mismo, con el remitente humano identificado.
- Documento con efecto económico o legal (cotizaciones, contratos, informes con cifras): revisa el dueño del proceso y se verifica cada dato contra su fuente. Registro: aprobación nominal.
- Código que entra al producto: revisa una persona distinta de quien lo generó, antes de fusionar. Registro: la revisión del cambio, con análisis de seguridad y verificación de licencias.
- Decisión sobre una persona (contratación, evaluación, crédito, acceso a un servicio): la IA sugiere, decide una persona; nunca al revés. Registro: la decisión, quién la tomó y en qué se basó.
- Contenido público a nombre de la empresa: revisa quien firma, y se verifica cada afirmación. Registro: aprobación antes de publicar.
Dos condiciones hacen que esto sea control y no trámite. El revisor tiene que poder rechazar sin fricción: si rechazar implica pedir permiso o retrasar una entrega, nadie va a rechazar. Y se registra cuántas salidas se rechazaron: un control de revisión con seis meses de cero rechazos no está revisando, está firmando.
Ejemplo resuelto: tres cláusulas redactadas
La diferencia entre una política que se aplica y una que se archiva está en la redacción. Tres pares de antes y después, tomados de los defectos más comunes:
Cláusula de información: de intención a regla
Antes: «Los colaboradores deberán abstenerse de compartir información sensible o confidencial en herramientas de inteligencia artificial, procurando en todo momento el resguardo de los activos informativos de la organización.»
Después: «No se introduce en ninguna herramienta de IA: datos personales de empleados, candidatos o clientes; credenciales de acceso; información cubierta por un acuerdo de confidencialidad con un cliente; ni código fuente del producto. La información interna no clasificada puede introducirse únicamente en las herramientas del anexo 1, con la cuenta corporativa. Ante la duda, se anonimiza el texto o se consulta al responsable de seguridad de la información.»
Cláusula de revisión: de adjetivo a procedimiento
Antes: «Todo contenido generado con IA deberá ser revisado y validado por personal competente antes de su utilización.»
Después: «Antes de enviarse a un cliente, todo texto generado o asistido por IA lo revisa el responsable de la cuenta, que verifica contra su fuente cada cifra, fecha, nombre y condición comercial. Los documentos con efecto económico o legal los aprueba además el dueño del proceso, y esa aprobación queda registrada. El contenido público a nombre de la empresa lo aprueba quien lo firma.»
Cláusula de decisiones sobre personas: de principio a límite
Antes: «La organización promueve el uso ético y no discriminatorio de la inteligencia artificial en sus procesos de gestión de personal.»
Después: «Ninguna decisión de contratación, promoción, evaluación de desempeño o terminación se toma de forma automatizada. Las herramientas de IA pueden ordenar o resumir información de candidatos, pero el descarte lo decide siempre una persona, que deja constancia del motivo. Está prohibido usar IA para inferir características personales de un candidato —edad, estado de salud, situación familiar— a partir de su documentación o de fuentes públicas.»
El patrón de las tres: sujeto concreto, verbo en presente de indicativo, objeto verificable y responsable nombrado. Nada de «deberá», «procurará» ni «en la medida de lo posible».
Aprobación, comunicación, aceptación y versión
Una política que nadie aceptó no es exigible, y este es el apartado que más se salta. Cinco pasos, todos con evidencia:
- Aprobación. La firma la dirección, no el área que la redactó. Queda la fecha y la versión.
- Comunicación. Se difunde por el canal formal de la empresa, con una sesión corta —no un correo con un adjunto— donde se explican los tres casos que más dudas generan.
- Aceptación. Cada persona alcanzada deja constancia de que la leyó y la acepta. Sin ese registro, el incumplimiento es difícil de sostener, y además es la evidencia que pide cualquier auditoría.
- Excepciones. Un mecanismo escrito: quién la pide, quién la autoriza, por cuánto tiempo y con qué control compensatorio. Sin vía de excepción, la gente no pide permiso: incumple en silencio.
- Vigencia y versión. Fecha de revisión —al menos anual, y siempre que entre una herramienta nueva o cambie la ley aplicable—, número de versión y control de cambios. El formalismo documental se hereda del manual de procedimientos: código, versión, fecha, responsable, historial.
Y la parte que la mayoría omite: la consecuencia. Una política sin consecuencia declarada no es una regla. La consecuencia se redacta con el marco laboral que la empresa ya tiene —el reglamento interior de trabajo y sus procedimientos— y no se inventa en el documento de IA.
8 errores de redacción que la vuelven papel
- Escribirla antes del inventario. Regula usos inexistentes y deja fuera los reales. Es el error que produce el 90 % de las políticas que nadie consulta.
- Copiarla de una plantilla genérica. Se nota en el primer párrafo: menciona herramientas que no se usan, áreas que no existen y riesgos que no aplican. El equipo deja de creerle.
- Redactar en potencial. «Deberá», «procurará», «se recomienda». Si no se puede decir si alguien la incumplió, no es una política.
- Confundir principios con reglas. Los principios ocupan un apartado corto; el resto son reglas. Una política que son cinco páginas de principios es un manifiesto.
- Congelar la lista de herramientas dentro del cuerpo. Queda obsoleta en un mes y obliga a reaprobar todo el documento. Va como anexo vivo.
- Prohibir sin alternativa. El uso se esconde y la empresa pierde la visibilidad que tenía.
- No decir qué pasa si se incumple. Sin consecuencia y sin aceptación registrada, es una recomendación con membrete.
- Publicarla y no formar. El documento no enseña a distinguir un caso límite. La sesión corta por área, con ejemplos del propio trabajo, es la que hace que la regla se aplique.
Cómo encaja con tu manual de políticas y con ISO 42001
La política de IA no vive suelta. Se apoya en documentos que probablemente ya tienes y alimenta a los que vengan después:
- Hacia arriba: forma parte del cuerpo de políticas de la empresa y hereda su formato, su codificación y su ciclo de revisión. No se inventa un estándar documental nuevo para ella.
- A los lados: se apoya en la política de seguridad de la información y en la clasificación de información —si existe un SGSI, esa clasificación ya está hecha—, y en el aviso de privacidad para lo que toque datos personales. Cuando hay un SGSI ISO 27001 operando, la política de uso de IA es una pieza más del cuerpo documental, no un sistema aparte.
- Hacia abajo: el anexo de herramientas, la guía de uso por área y el material de formación.
- Hacia la norma: en ISO/IEC 42001 la política de IA es un requisito de la cláusula 5.2 y el primer objetivo de control del Anexo A. Es decir: si algún día vas a certificarte, este documento ya te sirve, siempre que esté aprobado, comunicado, aceptado y revisado con evidencia.
Un dato para dimensionar el cuerpo documental que la acompaña cuando el sistema crece: en el SGSI ISO/IEC 27001:2022 completo que implantamos en una empresa de software, la política de uso aceptable es una de 34 políticas, junto con 25 procedimientos y 46 formatos. Una política de IA aislada es un buen primer paso; un cuerpo documental coherente es otra escala de proyecto, y conviene no confundirlos al planear.
Preguntas frecuentes
Doce apartados: objetivo, alcance, definiciones, principios, herramientas aprobadas y prohibidas, qué información puede introducirse, usos permitidos y prohibidos, revisión humana, etiquetado y transparencia, propiedad intelectual y confidencialidad, reporte de incidentes, y cumplimiento con excepciones y vigencia. Entre dos y cuatro páginas; más largo no se lee.
Nunca, en ninguna herramienta: datos personales de empleados, candidatos o clientes; credenciales y llaves de acceso; información cubierta por un acuerdo de confidencialidad; y código fuente propietario. La información interna no clasificada solo en herramientas aprobadas y con cuenta corporativa. Ante la duda, se anonimiza o se consulta al responsable designado.
Después. Una política escrita sin saber qué herramientas se usan, para qué y con qué datos regula una empresa imaginaria: deja fuera los usos reales y prohíbe cosas que nadie hace. El inventario se levanta por área, con amnistía declarada, y de él salen las reglas que la política escribe.
No. Para que sea exigible hacen falta cuatro evidencias: aprobación de la dirección con fecha y versión, comunicación por el canal formal, constancia de aceptación de cada persona alcanzada, y formación. Sin registro de aceptación, sostener un incumplimiento es difícil, y es justo el documento que pide una auditoría.
Al menos una vez al año, y siempre que ocurra un disparador: entra una herramienta nueva, cambia el plan contratado con un proveedor, cambia la legislación aplicable o hay un incidente. La lista de herramientas se mantiene como anexo vivo con su propia fecha de revisión, para no reaprobar el documento completo cada vez.
Puedes, pero rara vez funciona: sin una alternativa aprobada, el uso se mueve a cuentas personales y la empresa pierde toda visibilidad sobre qué información sale. Lo que sí se prohíbe con efecto es una lista corta y concreta de usos —automatizar decisiones sobre personas, introducir datos personales, conectar herramientas a sistemas internos sin alta— acompañada de herramientas aprobadas para lo demás.
Sí. La política de IA es un requisito de la cláusula 5.2 de ISO/IEC 42001 y el primer objetivo de control de su Anexo A. Si está aprobada por la dirección, comunicada, aceptada con registro y revisada periódicamente, ese requisito queda cubierto. Lo que la política no cubre es el resto del sistema: inventario, evaluación de impacto, ciclo de vida y gobierno de datos.
La redacta quien conozca la operación, no solo el área de sistemas, y la aprueba la dirección. Conviene que participen jurídico o cumplimiento —para la consecuencia y los contratos—, recursos humanos —para la aceptación y la formación— y al menos un área que use IA a diario, que es la que detecta si una regla es inaplicable antes de publicarla.
Conclusión
Una política de uso de IA sirve cuando alguien puede tomar una decisión con ella en la mano sin preguntarle a nadie. Eso no se consigue con más páginas ni con mejores principios: se consigue escribiendo reglas concretas sobre la información real de tu empresa, con ejemplos del trabajo que tu equipo hace.
Si vas a escribirla, tres decisiones ordenan el resto: levanta el inventario antes de redactar, saca la lista de herramientas a un anexo vivo para que el documento no envejezca en un mes, y cierra el ciclo de aceptación con registro —aprobación, comunicación, aceptación, formación—. Sin lo tercero tienes un texto; con lo tercero tienes una regla.
¿Quieres una política de IA que tu equipo pueda aplicar?
En Softgrade levantamos el inventario por área, escribimos la política con tu dirección, armamos el anexo de herramientas y capacitamos a quien la va a cumplir. Si después hace falta un sistema certificable, lo preparamos y lo auditamos internamente; el certificado lo emite un organismo acreditado bajo ISO/IEC 17021-1, que tú eliges.
Agenda un diagnóstico