Política de uso de IA en la empresa: qué debe contener y cómo redactarla

Casi todas las empresas descubren que necesitan una de estas el día que alguien pega en un asistente público algo que no debía. Hasta entonces la pregunta «¿puedo meter esto aquí?» se contesta en privado, distinta cada vez, y la respuesta depende del carácter de cada persona: los prudentes no usan nada y los confiados lo usan todo. Los dos resultados son malos, y el segundo es el único que se nota.

Un aviso sobre lo que no va a encontrar aquí: ni un solo porcentaje. Circulan muchas cifras sobre el uso de IA sin aprobación dentro de las empresas y no las hemos comprobado en su fuente primaria, así que no las repetimos. Lo que sigue es el contenido del documento y el modo de escribirlo.

¿Qué es una política de uso de IA?

Es la respuesta escrita, y una sola, a la pregunta que hoy cada persona de su empresa contesta por su cuenta: qué se puede hacer con estas herramientas y qué no. Se diferencia de una política de seguridad de la información en que no describe controles técnicos, sino decisiones concretas sobre tareas concretas: este tipo de documento sí, este no, este solo en la cuenta corporativa.

Y se diferencia de un curso en que sobrevive al curso. La formación cambia lo que la gente sabe hacer durante unas semanas; la política es lo que queda por escrito cuando esas semanas pasan y entra alguien nuevo. Por eso, en nuestros despliegues, la política se redacta durante las sesiones y a partir de lo que el equipo probó ese mismo día, no después y no por otra persona.

Las cinco preguntas que la política tiene que responder

Si el documento contesta estas cinco cosas con nombres propios, ya es utilizable. Si le falta una, la que falta es exactamente la que provocará el primer incidente.

• 1. Qué herramientas están aprobadas, y en qué cuenta. No basta con nombrar el producto. Hay que decir en qué tipo de cuenta se usa, porque el nivel corporativo y el gratuito del mismo producto suelen tratar los datos de forma distinta. «Está aprobado en la cuenta de empresa» y «está aprobado» no son la misma frase.
• 2. Qué no se introduce nunca. La parte más corta y la más importante. Debe estar redactada en términos que alguien reconozca mirando el documento que tiene delante, no en categorías abstractas de protección de datos.
• 3. Quién autoriza una excepción y cómo se pide. Sin este punto, la política no tiene válvula de escape y la gente la incumple en silencio en cuanto le estorba.
• 4. Qué ocurre con lo que se introduce. Dónde queda el historial, quién puede verlo, cuánto tiempo se conserva y si el proveedor lo utiliza para algo más. Si no lo sabe, la política debe decir que no lo sabe, y esa es una razón para no usar esa herramienta con datos de clientes.
• 5. Cada cuánto se revisa y quién lo hace. Con una fecha y un nombre. Una política sin propietario caduca en un trimestre.

¿Qué datos con qué herramienta? La tabla de clasificación

La forma más rápida de hacer utilizable una política es una tabla de tres columnas que una persona pueda mirar en diez segundos. Esta es la estructura que usamos; las categorías se rellenan con los documentos reales de la empresa, no con etiquetas genéricas.

Dos observaciones sobre esta tabla. La primera es que la columna de la derecha no es un permiso general: es una decisión que alguien de la empresa tiene que tomar, con nombre, y que la política registra. La segunda es que la fila del código fuente es la que más discusiones genera y la que más a menudo se olvida, porque quien escribe la política suele no ser quien escribe el código.

¿Qué no se introduce nunca en una herramienta externa?

La lista corta y sin matices, que es la única que se recuerda:

• Datos personales identificables de clientes, pacientes, alumnos o empleados, si la herramienta no está aprobada para tratarlos.
• Cualquier credencial: contraseñas, claves de API, tokens, certificados.
• Documentos sujetos a un deber de confidencialidad con un tercero, especialmente si el contrato con ese tercero no contempla el uso de herramientas de IA.
• Información que la empresa no podría enviar por correo electrónico sin cifrar a una dirección externa. Es la mejor prueba práctica y la que menos explicación necesita.

Esa última regla resuelve por sí sola la mayoría de los casos dudosos, y tiene la ventaja de que apela a un criterio que la gente ya tiene interiorizado.

El deber de comprobar antes de usar el resultado

La segunda mitad de una política de IA no trata de lo que entra, sino de lo que sale. Un resultado equivocado puede leerse exactamente igual de convincente que uno correcto, y esa es la propiedad que hace peligrosa a esta tecnología en manos sin criterio.

Un modo sencillo de escribirlo es fijar el nivel de comprobación según a dónde va el resultado:

La última fila es la que conviene no negociar. Si un resultado influye en una contratación, en un despido, en una calificación o en la concesión de algo, el nombre de quien decide tiene que estar escrito en algún sitio.

¿Quién autoriza una excepción y cómo se pide?

Toda política razonable admite excepciones, y las que no las admiten se incumplen a escondidas. Lo que hay que definir es tan simple como esto: a quién se le pide, en qué formato, y qué queda registrado. Tres líneas bastan.

Recomendamos que la excepción se pida por escrito, aunque sea por mensaje interno, que la conceda una sola figura, normalmente quien tiene la responsabilidad del sistema afectado, y que la respuesta indique un plazo. Una excepción sin fecha de caducidad se convierte en la regla nueva sin que nadie lo haya decidido.

¿Quién es el propietario de la política y cada cuánto se revisa?

Una persona, con nombre y apellidos, y una fecha en el pie del documento. Este es el punto donde fracasan más políticas, porque es el único que no se puede copiar de una plantilla.

Señales de que la política ya está desfasada, y que conviene revisar sin esperar a la fecha:

• Alguien menciona en una reunión una herramienta que no aparece en el documento.
• La empresa cambió el tipo de cuenta contratada en alguna herramienta, aunque el producto sea el mismo.
• Un cliente pregunta por escrito qué hace la empresa con sus datos cuando usa IA, y la política no contiene la respuesta.
• Ha entrado gente nueva y nadie recuerda quién les explicó las reglas.
• Se ha desplegado un sistema interno de IA nuevo y la política sigue hablando solo de asistentes públicos.

¿Qué relación tiene esto con el Reglamento de IA?

Directa y, además, tranquilizadora. El artículo 4 del Reglamento de Inteligencia Artificial, en la redacción vigente desde el 27 de julio de 2026, obliga a proveedores y responsables del despliegue de sistemas de IA a «adoptar medidas para apoyar la promoción de la alfabetización en materia de IA» de su personal, y precisa expresamente que esa obligación «no exige que los proveedores o los responsables del despliegue garanticen un nivel específico de alfabetización en materia de IA de ninguna persona en particular».

Una política interna, escrita, conocida por el equipo y revisada, es una de esas medidas, y probablemente la más barata. La Comisión Europea, preguntada por cómo documentar el cumplimiento del artículo 4, responde que «There is no need for a certificate. Organisations can keep an internal record of trainings and/or other guiding initiatives.» Es decir: no hace falta certificado, y basta con un registro interno de las formaciones y demás iniciativas de orientación. Su política, con su historial de versiones, es exactamente eso.

Cómo escribirla en una tarde, con el equipo

El error habitual es encargarla a una sola persona, que produce un documento correcto, largo y ajeno. La política se escribe con quien la va a cumplir, y por eso puede hacerse en una sesión.

Por qué fracasan la mayoría de estas políticas

Cuatro causas, por orden de frecuencia en lo que hemos visto al implantar sistemas.

• Es demasiado larga. Un documento de diez páginas se archiva y se cita, pero no se aplica. La longitud es una decisión de diseño, no un accidente.
• Prohíbe sin ofrecer alternativa. Si la política dice qué no se puede hacer y no dice con qué herramienta sí, el equipo vuelve a la herramienta prohibida en cuanto tiene prisa.
• La escribió alguien que no hace ese trabajo. Se nota en la primera lectura y desactiva el documento entero.
• No tiene propietario. Sin un nombre, nadie la actualiza cuando cambia una cuenta o entra una herramienta nueva, y a los seis meses describe una empresa que ya no existe.

Cuando un despliegue nuestro incluye un sistema interno que responde con los documentos de la propia empresa, la política gana además una parte que casi nunca aparece en las plantillas: qué se puede preguntar a ese sistema, quién ve qué respuestas y cómo se corrige una que ha quedado obsoleta. Eso lo explicamos en asistente de IA interno.