Una política de IA en marketing es el conjunto escrito de reglas sobre para qué puede usarse la IA, qué datos puede ver, y quién revisa su output antes de que salga del equipo. La gobernanza es la práctica que hace reales esas reglas —las revisiones, los registros y los dueños que convierten un documento en comportamiento—. Necesitas ambas, y la mayoría de los equipos no tiene ninguna o tiene una fingiendo ser la otra.
La razón por la que esto importa más en marketing que en muchas funciones es que el output de marketing toca directamente a clientes, marcas y contratos con clientes. Una mala línea de código es un bug; una mala línea de copy es una declaración pública. Esa asimetría es por qué la política tiene que existir antes de que escale el tooling, no después del primer incidente.
Política sin gobernanza es teatro
Una política que vive en una wiki y nunca se referencia es peor que ninguna política, porque crea la apariencia de control sin la sustancia. La gente asume que alguien la está aplicando. Nadie lo hace. La primera vez que algo sale mal, la política se convierte en evidencia de que el equipo conocía el riesgo y no hizo nada al respecto.
La gobernanza es la mitad poco glamurosa: quién firma un caso de uso nuevo, dónde vive el paso de revisión en el flujo de trabajo, qué se registra, y qué dispara un escalado. Es proceso, no prosa. Si tu gobernanza es solo una política, tienes un deseo, no un control.
Las cinco cosas que una política debe cubrir
Una política de IA en marketing viable responde cinco preguntas y deja el resto al modelo operativo. Mantenerla en estas cinco es lo que la hace lo bastante corta para ser leída y lo bastante específica para ser aplicada.
| Área | La pregunta que responde | Cómo se ve lo bueno |
|---|---|---|
| Uso permitido | ¿Para qué puede usarse la IA? | Listas explícitas de permitir, revisar y prohibir |
| Fronteras de datos | ¿Qué datos puede ver un modelo? | Reglas de cliente, personales y confidenciales |
| Divulgación | ¿Cuándo debe declararse su uso? | Reglas por canal y por contrato |
| Revisión | ¿Quién comprueba el output antes de que salga? | Rol nombrado y un paso definido |
| Responsabilidad | ¿Quién posee un fallo? | Un dueño nombrado, no «el equipo» |
Si una política no responde las cinco, será interpretada de forma distinta por cada persona que la lea, que es exactamente el estado que la gobernanza pretende evitar.
Fronteras de datos primero
La cuestión de las fronteras es la de mayor riesgo, así que zánjala primero. Los datos de cliente, los datos personales y cualquier cosa bajo contrato deberían tener reglas explícitas sobre qué herramientas pueden procesarlos y dónde pueden vivir. «No pegues datos de cliente en una herramienta pública» es un buen comienzo y un mal final, porque no dice a un operador ocupado qué puede hacer en su lugar.
La regla mejor es escalonada: una categoría de datos que puede ir a cualquier herramienta aprobada, una que solo puede ir a herramientas con un acuerdo de procesamiento de datos, y una que no puede salir de tus sistemas en absoluto. Luego haz el camino seguro el camino fácil, para que seguir la regla cueste menos que romperla. Una frontera que la gente puede cumplir gana a una frontera que sortea.
Divulgación y contratos con clientes
La divulgación es donde la política se encuentra con la relación con el cliente. Algunos clientes quieren saber cuándo se usa IA en su trabajo; algunos contratos ya lo exigen; algunos canales tienen sus propias reglas. La política debería decir cuál es tu default y cómo un cliente puede cambiarlo, en vez de dejar a cada equipo de cuenta improvisar.
El movimiento práctico es hacer de la divulgación una pregunta que haces al kickoff, no un apuro cuando un cliente la saca. Una cláusula corta que explique dónde se usa la IA y dónde no, acordada al principio, convierte una confrontación futura en una expectativa zanjada. La gobernanza es más barata cuando es proactiva.
Revisión y responsabilidad
Todo output asistido por IA que llega a un cliente o a un consumidor debería pasar un paso de revisión propiedad de un rol nombrado. La revisión no necesita ser pesada; necesita ser real, consistente y registrada. El punto es que un humano con responsabilidad miró el trabajo y decidió que era apto para salir.
Eso importa más, no menos, a medida que las herramientas se aceleran: una herramienta que permite a los revisores aprobar el output con un sello es un riesgo de gobernanza en vez de una ganancia de productividad —la dinámica de erosión del criterio que describí en por qué la mayoría de las herramientas de marketing con IA parecen rápidas pero debilitan el criterio del equipo —.
La responsabilidad es la mitad más difícil. Cuando algo sale mal, «el equipo» no posee nada. Nombra el dueño de cada clase de output, y dale la autoridad para parar el trabajo. Una política que asigna responsabilidad sin autoridad es una política que será ignorada la primera vez que le cueste un plazo a alguien.
Aplicarla sin frenar a todo el mundo
El miedo a que la gobernanza mate la velocidad es real y en su mayor parte evitable. El truco es incrustar los controles en el flujo de trabajo en vez de atornillarlos como aprobaciones. Si el paso de revisión es parte de cómo se mueve el trabajo, cuesta minutos; si es una puerta separada que alguien debe recordar, cuesta días y se salta bajo presión.
Empieza por los casos de uso más arriesgados y los controles más ligeros que de verdad los cubran, y luego expande. Un régimen de gobernanza que cubre todo desde el primer día será resentido y erosionado. Uno que empieza estrecho y se gana su alcance sobrevivirá al contacto con un trimestre ocupado. La pieza de cómo pilotar la IA es la compañera natural, porque un piloto es donde pruebas qué controles necesitas de verdad.
Un esqueleto de una página
Escribe la política como una página: usos permitidos en tres listas, una regla de datos escalonada, un default de divulgación y una pregunta de kickoff, un paso de revisión nombrado, y un dueño nombrado por clase de output. Añade un registro de cambios corto para que evolucione con las herramientas. Cualquier cosa más larga no se leerá; cualquier cosa más vaga no se seguirá.
Luego trata la gobernanza como la versión viva: una mirada mensual a qué casos de uso nuevos surgieron, qué revisiones atraparon algo, y si alguna regla necesita cambiar. Esa cadencia mantiene la política actual sin reescribirla constantemente, y da al equipo un lugar donde plantear los casos límite que un documento nunca puede anticipar del todo.
Empezar sin bloquear al equipo
La forma más rápida de hacer fracasar la gobernanza es lanzarla como una ofensiva. Los equipos bajo presión sortearán controles que les cuestan un plazo, y una política que resienten será tratada como una formalidad. Empieza por las dos o tres reglas que cubren el mayor riesgo —fronteras de datos de cliente y la puerta de revisión— y mantén todo lo demás como guía en vez de prohibición.
Haz el camino conforme el más rápido. Si la herramienta aprobada es más lenta que la no aprobada, la gente usará la no aprobada. Ofrece un default que sea seguro y fácil, para que seguir la política cueste menos que ignorarla. Luego expande las reglas a medida que el equipo construye los hábitos, y revísalas cuando cambien las herramientas. La gobernanza que crece con el uso se sigue; la gobernanza impuesta de golpe se audita en contra. Mantén un registro de cambios de una línea para que la gente vea que la política está viva en vez de tallada en piedra, y corre una revisión trimestral corta con quienes la usan, porque los casos límite que traen son los que el documento no puede predecir. Una política que el equipo ayuda a mantener es una que seguirán de verdad cuando importe.
Probar la política contra una semana real
Una política solo es tan buena como su comportamiento bajo presión, así que pruébala en una semana normal en vez de en abstracto. Coge tres cosas que el equipo entregó de verdad, y rastrea cada una: qué datos vio el modelo, quién revisó el output, y qué habría pasado si hubiera estado mal. Si alguna de las tres no puede responderse desde un registro, la gobernanza es aspiracional. Luego coge los casos límite sobre los que la gente ya refunfuña —un plazo apurado, un cliente que quiere velocidad, una herramienta que alguien prefiere— y decide ahora cómo los maneja la política, en vez de descubrir la respuesta durante un incidente. La política que sobrevive a este test es corta, específica y ligeramente molesta; la que falla es exhaustiva en papel y silenciosa en la práctica.
FAQ
¿Necesitamos una política si solo usamos herramientas aprobadas?
Sí, porque el riesgo rara vez es la herramienta y normalmente son los datos o el output. Las herramientas aprobadas igual procesan datos de cliente y producen copy que llega a consumidores. La política define las fronteras alrededor de ambos, independientemente de cómo se aprobó la herramienta.
¿Quién debería poseerla?
El liderazgo de marketing posee la política, con un operador nombrado dueño de la gobernanza del día a día. Legal y seguridad deberían revisar las fronteras de datos, pero la política no puede gestionarse desde legal, porque tiene que encajar con cómo funciona de verdad el marketing. La propiedad dentro de marketing es lo que la hace aplicable.
¿Con qué frecuencia debería cambiar?
Revisa los bordes mensualmente y el documento entero cada trimestre. Las herramientas se mueven más rápido que los ciclos de política, así que un registro de cambios y una cadencia de revisión corta importan más que una reescritura exhaustiva. El objetivo es un one-pager actual, no un proyecto anual.
¿Una política nos frena?
Mal hecha, sí. Hecha como parte del flujo de trabajo, añade minutos y previene el tipo de incidente que cuesta semanas. Los equipos que encuentran lenta la gobernanza normalmente la construyeron como una capa de aprobación separada en vez de incrustarla en cómo ya se mueve el trabajo.
La versión corta
Una política de IA en marketing define qué puede tocar la IA, qué puede ver, quién la revisa y quién posee un fallo. La gobernanza es la práctica que hace reales esas reglas dentro del flujo de trabajo. Mantén la política en una página, zanja las fronteras de datos primero, y aplícala a través del trabajo en vez de alrededor. La guía de Ejecución sitúa la gobernanza en el modelo operativo más amplio, y el carril para equipos in-house la trabaja para un equipo del lado del cliente.
Si tu equipo ha escrito una de estas, me gustaría saber qué regla resultó importar más en la práctica.
Un abrazo, Chandler
Este artículo está disponible en español, pero los materiales del curso (videos, plantillas y guías complementarias) están en inglés y japonés; este sitio está disponible en 13 idiomas.