La mayoría de las políticas de uso de inteligencia artificial que llegan a nuestras manos tienen entre quince y treinta páginas, un glosario extenso, una sección de principios y una lista de prohibiciones. Están bien escritas y nadie las lee. Se firman en la plataforma de capacitación, se archivan y no vuelven a aparecer hasta la siguiente auditoría. En términos de control efectivo, esa política vale cero.
Vale menos que cero, en realidad. Una política extensa que nadie cumple es peor que no tener ninguna, porque la organización queda afirmando ante terceros que tiene un control que en los hechos no opera. Cuando ocurre un incidente, la existencia del documento no protege: agrava, porque demuestra que el riesgo estaba identificado y aun así no se gestionó.
Por qué fallan las políticas largas
El problema de origen es que se escriben para proteger a quien las redacta, no para guiar a quien las tiene que cumplir. Eso produce tres efectos concretos.
El primero es la redacción defensiva: se cubren todos los escenarios imaginables con lenguaje amplio, y la amplitud destruye la operabilidad. "Se debe usar la inteligencia artificial de manera responsable y ética" no permite a nadie saber si está cumpliendo, y tampoco permite a nadie constatar un incumplimiento. El segundo es la mezcla de lo estable con lo volátil: la política incluye la lista de herramientas aprobadas, que cambia cada pocas semanas, de modo que o queda desactualizada o exige un ciclo completo de aprobación cada vez que alguien contrata un servicio nuevo. En la práctica queda desactualizada, y una política visiblemente vencida enseña a la organización que este documento no se toma en serio. El tercero es que empiezan por las prohibiciones. Quien lee busca saber qué puede hacer; si las primeras tres páginas dicen qué no puede hacer, deja de leer y resuelve por su cuenta, que es exactamente el comportamiento que la política pretendía evitar. Sobre cómo se ve ese comportamiento en los datos, escribimos en el artículo sobre inventario de Shadow AI.
Extensión y estructura que sí funcionan
La parte que lee una persona común debería caber en dos páginas. Todo lo demás —listas de herramientas, clasificación de datos, procedimientos por área, cláusulas para proveedores— va en anexos que se actualizan sin reabrir el documento principal. Esa separación entre lo que cambia una vez al año y lo que cambia cada mes es la decisión de diseño más importante, y la que casi nadie toma.
El orden que mejor nos ha funcionado es este:
- A quién aplica y a qué. Una frase, sin condicionales. Si el lector tiene que interpretar si le corresponde, ya perdiste.
- Lo que sí puedes hacer. Los usos habilitados, nombrados por tarea real y no por categoría abstracta: redactar borradores internos, resumir documentación pública, generar código que después se revisa. Empezar por aquí compra la atención del lector.
- Las reglas duras. Pocas, absolutas y verificables. Qué información nunca entra a una herramienta de IA. Qué salidas requieren revisión humana antes de usarse. Qué acciones no ejecuta nunca un sistema automático sin confirmación explícita.
- Qué hacer cuando tu caso no aparece. Un canal concreto, una persona o buzón, y un compromiso de tiempo de respuesta. Sin esto, cada vacío se resuelve silenciosamente y en contra de la política.
- Qué pasa si te equivocas. Declarar explícitamente que reportar un error a tiempo no acarrea consecuencias disciplinarias. Sin esa cláusula, los incidentes se ocultan y la organización se entera cuando ya no puede contenerlos.
Reglas verificables en lugar de principios
Una regla sirve si puedes responder, mirando algo observable, si se cumplió o no. Ese es todo el criterio. "Toda comunicación externa generada con asistencia de IA se revisa por una persona identificable antes de enviarse" es verificable: hay un remitente, hay un registro, hay alguien a quien preguntar. "Las comunicaciones deben mantener los estándares de calidad de la organización" no lo es.
Una regla que nadie puede verificar no es una regla: es una declaración de intenciones con formato de norma.
Dos criterios prácticos ayudan al redactar. Primero, cada regla necesita una acción observable, un alcance definido y alguien que pueda constatarla; si falta cualquiera de los tres, la regla no va a operar. Segundo, conviene escribir en positivo y por lista blanca: decir qué categorías de información pueden entrar a cada herramienta funciona mucho mejor que enumerar prohibiciones, porque las prohibiciones siempre dejan fuera el caso nuevo y obligan al lector a interpretar.
Cómo mantenerla viva
Una política tiene que tener dueño con nombre, no un área. Los anexos deben poder actualizarse por decisión del órgano de gobierno, sin pasar por la aprobación completa que requiere el cuerpo principal; si actualizar la lista de herramientas cuesta lo mismo que cambiar la política, la lista no se va a actualizar.
La revisión no debería depender solo del calendario. Hay eventos que la gatillan de inmediato: la aparición de una categoría de herramienta que la política no contempla, un incidente, un cambio contractual relevante con un proveedor de modelos, o un cambio normativo —y en Chile ese frente sigue en movimiento, como seguimos en nuestra página sobre la Ley IA.
Para saber si está viva, no mires el porcentaje de personas que firmaron la capacitación: ese número solo indica que el sistema de aprendizaje funciona. Mira cuántas consultas llegan por el canal de casos no cubiertos. Cero consultas al mes no significa que la política sea perfecta; significa que nadie la está usando para decidir, y que las decisiones que ella debería estar guiando se están tomando en otra parte, sin registro. Empieza por ahí: cuenta las consultas del último trimestre y compara ese número con la cantidad de herramientas de IA nuevas que aparecieron en el mismo período. La brecha entre ambos es el tamaño real de tu problema.