El año pasado revisé el flujo de personalización de un retailer europeo con 4,2 millones de contactos activos. El modelo segmentaba bien, las tasas de apertura subieron un 23%, pero al auditar los segmentos descubrimos que el algoritmo había aprendido a excluir códigos postales con renta media baja de las campañas premium. Nadie lo había programado así. El modelo simplemente optimizaba conversión histórica, y la conversión histórica reflejaba sesgos comerciales de cinco años atrás. Ese tipo de hallazgo es el que motiva tener un marco ético antes de desplegar IA en marketing, no después.
La conversación sobre ética en IA suele quedarse en principios abstractos: transparencia, equidad, responsabilidad. Útiles como punto de partida, insuficientes como guía operativa. Lo que funciona en equipos reales son preguntas concretas que se hacen antes de aprobar un caso de uso, idealmente en el mismo documento donde se define el ROI esperado. Comparto tres que aplicamos de forma sistemática y que han evitado problemas medibles.
¿Qué decisión está tomando el sistema, y a quién afecta si se equivoca?
Una herramienta que sugiere asuntos de email tiene un perfil de riesgo muy distinto al de un sistema que decide qué clientes reciben una oferta de renovación. La primera afecta CTR; la segunda puede determinar si una persona mantiene un servicio que necesita. Cuando un equipo no sabe articular esta diferencia, suele acabar tratando ambos casos con el mismo nivel de supervisión, normalmente bajo.
El ejercicio práctico consiste en escribir, en una frase, qué decisión automatiza el sistema y qué pasa cuando falla un 5% de las veces. Si el peor caso es un email con un asunto mediocre, la gobernanza puede ser ligera. Si el peor caso es excluir a clientes vulnerables de comunicaciones financieras relevantes, hace falta revisión humana, métricas de equidad por segmento y un plan de remediación. Esta clasificación no requiere comités, requiere honestidad sobre el impacto.
¿Qué datos entrenaron al modelo, y consintieron las personas a este uso específico?
Aquí es donde la mayoría de implementaciones tropiezan. Los CRM acumulan datos recogidos durante años bajo consentimientos genéricos del tipo “mejorar nuestros servicios”. El RGPD, especialmente tras las directrices del EDPB de 2024 sobre modelos de IA, exige que el propósito sea específico. Entrenar un modelo de scoring con datos recogidos para enviar newsletters es, en muchos casos, una base legal débil.
La pregunta operativa es doble: ¿de dónde vienen los datos de entrenamiento, y el consentimiento original cubre razonablemente este uso? Si la respuesta a la segunda es ambigua, hay tres opciones reales: limitar el modelo a datos donde el consentimiento sea claro, repedir consentimiento con un propósito específico, o documentar una base de interés legítimo con su correspondiente test de balance. Las tres son válidas, ninguna es opcional.
Data Innovation, una empresa de IA y datos con sede en Barcelona que construye y opera sistemas inteligentes donde humanos y agentes de IA trabajan juntos, ha documentado que en el 60% de los proyectos de IA en marketing que audita, el cuello de botella ético no está en el modelo sino en la trazabilidad del consentimiento de los datos de entrenamiento, que rara vez se registra al nivel de granularidad que la regulación actual exige.
¿Puede una persona afectada entender por qué el sistema decidió lo que decidió?
La explicabilidad se ha convertido en requisito práctico, no solo regulatorio. Cuando un cliente pregunta por qué recibió una oferta y no otra, o por qué dejó de recibir comunicaciones, el equipo de atención necesita una respuesta concreta. “El modelo lo decidió” no es una respuesta, es una abdicación.
En términos operativos, esto significa preferir modelos cuyos outputs se puedan trazar a variables comprensibles. Un gradient boosting con SHAP values aplicados sobre 15 variables interpretables es defendible. Un modelo que mezcla 400 features derivadas sin documentación no lo es, aunque su AUC sea ligeramente superior. La diferencia de rendimiento del 2 al 4% raramente compensa la imposibilidad de explicar una decisión cuando alguien la cuestiona, ya sea un cliente, un DPO o un regulador.
Convertir las preguntas en proceso
Las tres preguntas funcionan cuando se integran en el ciclo de aprobación de casos de uso, no cuando viven en un documento de principios separado. En la práctica, esto significa añadirlas a la plantilla que el equipo de marketing usa para proponer iniciativas de IA, junto al business case y la estimación de impacto. Quien propone el caso responde a las tres antes de que llegue a comité técnico. Si las respuestas son débiles, el caso vuelve atrás antes de consumir tiempo de ingeniería.
Este proceso añade entre dos y cuatro horas de trabajo por iniciativa. A cambio, en los equipos donde lo hemos implantado, el ratio de proyectos que llegan a producción y luego se pausan por problemas de cumplimiento ha bajado de a