La tesis en una frase: una política que no se puede ejecutar no es una política, es un descargo de responsabilidad. Sirve para enseñarla en una auditoría y no sirve para cambiar lo que el sistema hace el martes por la tarde. La diferencia entre las dos cosas no es el rigor con que está escrita: es si alguien tradujo cada frase en una condición que una máquina puede comprobar antes de dejar salir una acción.
Una política de uso de IA en la empresa que no se puede ejecutar no es una política
El patrón se repite en todas las empresas que ya pasaron la fase del entusiasmo. Alguien redacta la política de uso de IA en la empresa —seis páginas, bien escritas, revisadas por legal—, se sube a la intranet, se comunica por correo y se da el asunto por cerrado. Tres meses después hay agentes escribiendo a clientes, comprometiendo importes y publicando afirmaciones sobre el producto, y ninguna de esas acciones pasa por nada que se parezca a lo que dice el documento. No porque alguien lo incumpla a propósito: porque el documento nunca se conectó a nada.
El género literario está saturado de la parte fácil. Hay plantillas, checklists y guías sobre qué hay que documentar: alcance, roles, usos prohibidos, clasificación de riesgo, responsable. Todo eso es necesario y ninguno de esos textos explica la parte que cuesta, que es la siguiente: cómo esa frase escrita en castellano se convierte en una comprobación que corre en producción y que puede parar una acción. Ese salto es el trabajo real, y es el que casi nunca se hace.
Conviene decirlo sin rodeos porque hay dinero de por medio: una política que solo existe en PDF no te protege de nada salvo, con suerte, de una parte de la responsabilidad. No evita el error, no lo detecta y no deja rastro de que se intentó evitarlo. Si lo que quieres es que la IA se comporte, hay que bajar el documento tres niveles: de principio a regla, de regla a condición comprobable, y de condición a evidencia.
Paso 1: descomponer la obligación en condiciones comprobables
Coge cada frase de la política y hazle una sola pregunta: ¿qué tendría que ser cierto, en una acción concreta, para que esta frase se esté cumpliendo? Si la respuesta es larga, ambigua o depende del criterio de quien mire, la frase todavía no es una regla: es una intención. Hay que partirla hasta que cada trozo sea verificable con un sí o un no.
Un ejemplo típico. «La IA se usará de forma transparente con los clientes» no es comprobable. Descompuesta, se convierte en tres condiciones que sí lo son: en toda conversación iniciada por un sistema automático, el primer mensaje declara que es un sistema automático; en cualquier canal donde el cliente pueda pedir una persona, existe una vía visible para hacerlo; y ningún mensaje afirma o insinúa que lo escribe una persona concreta del equipo. Tres condiciones, tres comprobaciones posibles. El principio original sigue ahí, pero ahora se puede cablear.
Dos avisos sobre este paso. El primero: la descomposición es donde se toman las decisiones difíciles, no en la redacción del principio. «Transparente» suena a que todos estamos de acuerdo; «el primer mensaje declara que es un sistema automático» abre una discusión real sobre marketing, conversión y tono. Esa discusión hay que tenerla, y tenerla aquí es mucho más barato que tenerla después de un incidente. El segundo: si una obligación no se puede descomponer en condiciones comprobables, escríbelo también. Hay obligaciones que solo se cumplen con criterio humano, y marcarlas como tales es información útil, no un fracaso.
Paso 2: decidir con qué evidencia se comprueba cada condición
Una condición sin evidencia asignada es una condición que nadie comprueba. Y aquí aparece el sesgo que arruina la mayoría de los intentos: si la evidencia la elige quien tiene que implementarla, va a elegir la fácil de obtener, no la que de verdad demuestra el cumplimiento. Es humano y es predecible, así que se corrige por diseño.
Para cada condición hay que fijar tres cosas: qué dato la demuestra, en qué momento se mira y quién responde si falta. La evidencia puede ser muy simple —el texto del primer mensaje enviado, el importe del campo de la operación, la lista de fuentes que el sistema usó para redactar—, y cuanto más simple, mejor: una comprobación que solo funciona si todo el pipeline está sano no es una comprobación, es una esperanza.
El momento importa tanto como el dato. No es lo mismo comprobar antes de ejecutar —el sistema se para y no pasa nada— que comprobar después —el sistema actúa y tú te enteras—. Las dos son válidas y no cuestan lo mismo. La regla práctica: todo lo que sea irreversible o visible para el cliente se comprueba antes; lo demás puede comprobarse después, siempre que exista alguien mirando el registro y un plazo escrito para mirarlo. Los mecanismos que hacen esto posible —registro, permisos con alcance, freno de mano y auditoría— están desarrollados en gobernanza y control de la automatización con IA; lo que aquí añadimos es la parte de arriba: qué se comprueba y por qué, no con qué se comprueba.
Paso 3: definir qué pasa cuando falla
Este es el paso que casi nadie escribe y el único que decide si el control existe de verdad. Una comprobación sin consecuencia definida acaba siempre en el mismo sitio: un aviso en un panel que nadie abre. Para cada condición hay que decidir, por adelantado, una de cuatro respuestas: se bloquea la acción, se escala a una persona con el caso ya montado, se registra y se deja pasar, o se degrada a una versión más conservadora de la misma acción.
Elegir «bloquear» para todo es tan mal diseño como elegir «registrar» para todo. Bloquear todo convierte el sistema en inútil y la organización aprende rapidísimo a saltárselo; registrar todo produce un archivo perfecto de incumplimientos que nadie leyó. La pregunta que ordena la elección es la de siempre: cuánto cuesta el error y cuánto tarda en verse. Error caro y visible, escalar. Error caro e invisible, bloquear. Error barato y visible, registrar. Y una condición extra que se olvida: la respuesta «escalar» solo es legítima si hay capacidad humana real para atender ese volumen. Si escalas más casos de los que tu equipo puede mirar, la cola se aprueba en bloque sin leer, que es peor que no tener control, porque además genera un registro falso de revisión. Ese es exactamente el problema que se aborda en supervisión humana de IA a escala.
Tres ejemplos concretos y baratos con los que empezar
No hace falta cablear la política entera para que el ejercicio valga la pena. Tres controles bien elegidos cubren la mayor parte del riesgo real de una empresa que empieza, y los tres se implementan en días, no en trimestres.
- Avisar de que es IA. Condición: toda conversación iniciada o sostenida por un sistema automático declara que lo es en el primer mensaje. Evidencia: el texto enviado. Momento: antes de enviar. Fallo: se bloquea el envío. Además de ser lo correcto, desde el 2 de agosto de 2026 hay una obligación de transparencia europea aplicable a los sistemas destinados a interactuar directamente con personas, que deben diseñarse de forma que la persona sepa que está interactuando con una IA, salvo que resulte obvio. Fuente: Comisión Europea, Transparency obligations under Article 50 of the AI Act (Reglamento (UE) 2024/1689), consultado el 14 de septiembre de 2026. Conviene mirarlo con tu asesoría: el alcance y la figura que te aplica —proveedor o responsable del despliegue— dependen de tu caso, y esto no es asesoramiento legal.
- Límite de importe que un agente puede comprometer. Condición: ninguna acción que comprometa dinero supera el umbral fijado por operación y por día. Evidencia: el importe del campo, más un acumulado diario. Momento: antes de ejecutar. Fallo: escala a una persona con el caso montado. Es el control más barato de todos y el que más gente descubre tarde, normalmente después del primer susto.
- Afirmaciones que exigen fuente aprobada. Condición: cualquier mensaje al cliente que contenga un dato de producto, precio, plazo o condición se apoya en una fuente de una lista aprobada. Evidencia: las fuentes que el sistema recuperó para redactar. Momento: antes de enviar. Fallo: degrada —el sistema manda una respuesta sin ese dato y ofrece traspaso— en vez de bloquear, que aquí sería exagerado.
Nótese lo que tienen en común: los tres se expresan en una línea, los tres tienen una evidencia obvia y los tres tienen una consecuencia distinta. Esa asimetría es la señal de que el ejercicio se ha hecho bien. Si los tres acabaran en «bloquear», es que nadie se paró a pensar en el coste de cada error. El alcance de lo que el agente puede tocar para empezar es otra decisión de este mismo ejercicio, y está en qué permisos darle a un agente de IA.
El error caro: dejar que la política la escriba solo ingeniería
Cuando la traducción de política a control se delega entera al equipo técnico, pasa algo perfectamente razonable y perfectamente equivocado: se acaba comprobando lo que es fácil de comprobar, no lo que la política obliga. El resultado tiene buena pinta —hay reglas, hay registros, hay paneles— y deja fuera justo lo que más importa, porque lo que más importa casi nunca es lo más medible.
Se ve en detalles pequeños. Se comprueba que el mensaje no supera una longitud, y no que no promete un plazo que no puedes cumplir. Se comprueba que la respuesta cita una fuente, y no que la fuente esté aprobada. Se comprueba que la operación tiene un importe, y no que ese importe respete el límite que alguien decidió en un comité. Cada una de esas comprobaciones es correcta y ninguna es la que la política pedía.
El antídoto es de proceso, no de tecnología: la descomposición del paso 1 la hace quien es dueño de la obligación —negocio, legal, operaciones— y la evidencia del paso 2 se pacta entre esa persona y quien lo va a implementar. Ingeniería tiene derecho de veto sobre lo imposible y no sobre lo incómodo. Y el documento final se firma por los dos lados, con fecha. Sin esa firma cruzada, lo que hay no es una política ejecutable: es una lista de lo que resultó cómodo medir.
Hay un matiz de orden que también conviene respetar, y va en contra de lo que parece obvio: la política no se escribe primero. Se escribe cuando ya sabes qué estás regulando, y eso lo averiguas mirando lo que tu gente ya hace con la IA sin pedir permiso —el argumento completo está en por qué prohibir el shadow AI no funciona—. Una política redactada antes de ese inventario regula una empresa imaginaria.
Cómo se ve una política ejecutable cuando está terminada
No se parece a un documento legal. Se parece a una tabla, y cabe en una página por cada área. Cada fila tiene seis columnas: la obligación de la que sale, la condición comprobable, la evidencia, el momento en que se mira, qué pasa si falla, y quién responde. Debajo, una lista aparte con las obligaciones que decidiste que no son automatizables y que por tanto dependen de una persona, con su nombre y su cadencia de revisión.
Esa tabla tiene una propiedad que el PDF no tiene: se puede auditar contra la realidad. Coges una fila, coges un caso de la semana pasada y compruebas si la condición se evaluó, con qué evidencia y qué pasó. O sale el registro, o la fila es mentira. Es una prueba de cinco minutos y es la única forma honesta de saber si tu política de uso de IA en la empresa está viva o es decoración.
Y tiene otra: envejece de forma visible. Cuando cambia una obligación, cambia una fila y se ve qué controles hay que tocar. Cuando el PDF cambia, no cambia nada, porque no estaba conectado a nada. Por eso el entregable que dejamos en Adopción IA para equipos no es el documento: es esa tabla, con dueño y fecha de revisión, y los controles del primer tramo ya montados. El documento sigue haciendo falta —hay que poder enseñarlo—, pero es la consecuencia del trabajo, no el trabajo.