Una política útil empieza por reconocer lo que no es
El Reglamento de IA no exige una política con este nombre. Tampoco publica un índice obligatorio ni fija una revisión anual para una política general de uso interno.
Eso no vuelve inútil el documento. Una política puede resolver un problema muy concreto: que las decisiones sobre herramientas, datos y revisión de resultados no vivan solo en conversaciones dispersas. Su valor depende de que describa cómo trabaja realmente la organización y de que el equipo pueda aplicarla.
Conviene llamarla política interna o borrador de gobernanza, no prueba de conformidad. La aprobación del texto no sustituye la revisión de una finalidad concreta, un contrato con el proveedor o una obligación sectorial.
Seis módulos recomendados, no seis requisitos legales
Esta estructura editorial es un punto de partida. Puedes recortarla o ampliarla según el uso.
1. Objeto, alcance y responsables
Define a quién se aplica, qué actividades cubre y quién puede aprobar una herramienta o resolver una duda. Distingue entre uso personal no profesional y uso por cuenta de la organización.
2. Sistemas y finalidades autorizadas
Nombra los sistemas aprobados y la finalidad permitida. Autorizar una herramienta para resumir documentos internos no implica autorizarla para evaluar candidaturas o responder de forma autónoma a clientes. Un inventario interno de sistemas puede mantener esta relación sin convertirla en un registro legal universal.
3. Datos e información que requieren control
Indica cuándo no se deben introducir datos personales, información confidencial, secretos empresariales o material sujeto a derechos de terceros. Evita una prohibición genérica que nadie pueda interpretar. Relaciona la regla con los contratos, configuraciones y procedimientos de seguridad reales.
4. Revisión de resultados
Ajusta la revisión al impacto. Un borrador interno de bajo impacto y una recomendación que influye en una decisión sobre una persona no merecen el mismo control. Pide comprobar fuentes, corregir errores y documentar la intervención humana cuando sea relevante.
5. Incidencias y cambios
Da un canal claro para comunicar salidas erróneas con impacto, sesgos, filtraciones, usos no autorizados, cambios de finalidad o nuevas herramientas. Explica quién evalúa el incidente y cuándo se suspende un uso.
6. Transparencia y revisión jurídica
No copies una frase que ordene etiquetar todo contenido generado con IA. El artículo 50 asigna deberes distintos:
- El proveedor responde por la información en interacciones directas y por el marcado técnico del contenido sintético.
- El responsable del despliegue informa en usos de reconocimiento de emociones o categorización biométrica.
- El responsable del despliegue revela ultrasuplantaciones y cierto texto sobre asuntos de interés público.
La política puede exigir que se compruebe el rol y el supuesto antes de publicar un aviso. Eso evita tanto el silencio como el etiquetado indiscriminado.
Cómo incorporar el artículo 4 sin inventar un certificado
El artículo 4, tras el Reglamento (UE) 2026/1744, exige medidas para apoyar el desarrollo de la alfabetización en IA entre el personal y otras personas que operen o usen sistemas por cuenta del proveedor o responsable del despliegue. La elección debe considerar conocimientos técnicos, experiencia, educación, formación, contexto y personas afectadas. No exige garantizar un nivel específico de una persona.
La Comisión Europea explica que no existe una solución única, un certificado obligatorio ni una estructura de gobernanza específica. Una política puede apoyar esas medidas con instrucciones, ejemplos y responsables. No reemplaza la formación práctica que necesite cada equipo.
Una forma sencilla de redactar esta sección es responder tres preguntas:
- ¿Quién usa cada sistema y qué sabe ya?
- ¿Qué errores o daños puede producir ese uso?
- ¿Qué instrucción, práctica o supervisión reduce esos riesgos?
Conservar la versión aprobada, las comunicaciones y las actividades realizadas puede ser útil como evidencia interna. No las presentes como una certificación oficial.
Cuándo revisar la política
Una fecha fija puede ayudar como recordatorio, pero no debe venderse como mandato del Reglamento. Los eventos de revisión más importantes son:
- incorporación o retirada de un sistema;
- cambio de finalidad, configuración o proveedor;
- uso con nuevas categorías de datos o personas afectadas;
- incidente, reclamación o resultado inesperado;
- nueva guía oficial o cambio normativo;
- cambio en la evaluación de riesgo o en el rol de la organización.
Si nada ha cambiado, una lectura periódica puede seguir siendo una buena práctica. La razón es de mantenimiento, no una frecuencia legal inventada.
Cómo usar la plantilla de GDPR.Direct
La plataforma toma los sistemas que has descrito y genera un borrador editable. Antes de aprobarlo:
- elimina sistemas de ejemplo o finalidades que no existan;
- comprueba que las reglas coinciden con las capacidades contratadas;
- asigna responsables y canales que funcionen;
- revisa por separado cualquier posible práctica prohibida o uso de alto riesgo;
- elige avisos del artículo 50 solo después de confirmar el rol y el supuesto.
Crear un borrador de política interna →