IAB TCF v2.4: Lo que los CMP deben cambiar para octubre de 2026

IAB TCF v2.4 ahora tiene un cronograma de implementación confirmado. IAB Europe planea publicar las especificaciones técnicas finales y la Lista Global de Proveedores (GVL) actualizada el 23 de julio de 2026. Los CMP tienen hasta el 23 de octubre de 2026 para implementaciones web y hasta el 23 de febrero de 2027 para entornos de aplicaciones móviles y TV conectada. Si tu pila de consentimiento participa en el TCF, este es un proyecto de implementación, no solo una actualización de banner de redacción.

Los cambios se encuentran en la Política TCF v5.0.b y las Especificaciones Técnicas v2.4. Afectan cómo los CMP explican las Características, divulgan el alcance de una elección, apoyan el consentimiento multi-dispositivo y codifican un caso de señalización de proveedores restringido. Para obtener más información sobre el marco actual, consulta el resumen de cumplimiento de IAB TCF de Conzent.

Conclusiones clave

Las fechas confirmadas brindan a los CMP y editores una secuencia corta pero viable: inspeccionar el paquete final en julio, finalizar los cambios web en octubre y mantener móvil y CTV en un plan separado para febrero. Los puntos más importantes son:

• 23 de julio de 2026: IAB Europe planea publicar las Especificaciones Técnicas v2.4 y la actualización correspondiente de la GVL.
• 23 de octubre de 2026: Los CMP deben implementar las nuevas divulgaciones en entornos web.
• 23 de febrero de 2027: la fecha límite equivalente se aplica a entornos de aplicaciones móviles y CTV.
• Las interfaces de CMP necesitan explicaciones y ilustraciones estándar más claras para las Características.
• La capa inicial debe informar a los usuarios si una elección es específica del servicio, específica del grupo o multi-dispositivo.
• La vista previa técnica elimina una solución de interés legítimo obsoleta para proveedores que declaran solo Propósitos Especiales; los equipos deben verificar la redacción final el 23 de julio.
• La participación en el TCF apoya el trabajo de cumplimiento, pero no reemplaza la evaluación legal propia de un editor o proveedor.

Las tres fechas que debes incluir en tu plan de entrega

La confirmación de IAB Europe con fecha del 16 de julio de 2026 establece tres hitos separados. Tratar estos como una sola fecha límite comprimiría el descubrimiento, la implementación, la traducción y la QA en la misma ventana de lanzamiento.

La secuencia práctica es:

1. 23 de julio de 2026 — publicación de especificaciones y GVL. Descarga los archivos finales, compáralos con el material de comentarios públicos y convierte cada diferencia confirmada en una tarea propia.
2. 23 de octubre de 2026 — fecha límite web. Los CMP web en producción deben exponer las nuevas divulgaciones y seguir los requisitos de señalización finales v2.4.
3. 23 de febrero de 2027 — fecha límite para aplicaciones y CTV. Los SDK nativos, los plazos de lanzamiento en tiendas, las interfaces de televisión y las pruebas de accesibilidad específicas de dispositivos tienen una fecha posterior, no una exención.

La brecha entre la publicación y la fecha límite web es de tres meses. Eso es suficiente para una actualización controlada si los equipos comienzan con una diferencia de especificaciones y una matriz de pruebas. Es ajustado si el trabajo comienza con un rediseño tardío del banner.

La secuencia confirmada separa el material fuente, la implementación web y el lanzamiento de la aplicación/CTV. Planifica y prueba estos como tres hitos en lugar de un solo lanzamiento.

Quién debe actuar—y quién aún debe prestar atención

Las fechas límite se aplican a las implementaciones TCF en vivo y a los CMP responsables de ellas. Las Políticas TCF oficiales cubren tanto los CMP comerciales que atienden a clientes como los CMP privados operados por un editor para sus propias propiedades. Los editores siguen siendo responsables de la interfaz del marco presentada en sus propiedades digitales, incluso cuando un tercero proporciona el CMP.

Debes incluir este trabajo en un plan de entrega si:

• construyes o operas un CMP TCF registrado;
• utilizas un CMP comercial en un sitio web financiado por publicidad programática;
• mantienes un CMP privado de editor;
• ofreces la misma experiencia de consentimiento en web, aplicación y CTV;
• dependes de señales TCF para proveedores, pujas, medición o anuncios personalizados.

Un sitio web que no participa en el TCF no está automáticamente obligado a implementar TCF v2.4. Aún puede necesitar un mecanismo de consentimiento válido bajo la ley aplicable o las reglas de la plataforma. La versión del marco y el deber legal de obtener consentimiento son preguntas relacionadas, pero no la misma pregunta.

Esta distinción es importante para los productos de Google para editores. Google requiere un CMP certificado integrado con el TCF para anuncios personalizados servidos a través de AdSense, Ad Manager o AdMob a usuarios en el EEE, Reino Unido y Suiza. Google también afirma que su revisión de certificación no verifica el cumplimiento total con el TCF o la ley de privacidad aplicable.

Qué verán los usuarios de manera diferente en un CMP

El cambio más visible es un esfuerzo por explicar Características de manera más clara. En el TCF, un Propósito describe por qué se procesan los datos y da al usuario una opción de consentimiento u objeción donde sea aplicable. Una Característica describe un método de procesamiento utilizado en busca de uno o más Propósitos; no lleva un control de usuario separado de la misma manera.

Bajo la Política v5.0.b y la actualización de GVL confirmada, los CMP deben tener en cuenta:

• un nuevo campo standardTexts que contiene la explicación estándar para las Características;
• ilustraciones para cada Característica en la GVL actualizada;
• la explicación estándar de la Característica mostrada con el nombre estándar y texto completo amigable para el usuario;
• información de la Característica que no está visualmente asociada con controles que no pueden desactivar realmente la Característica;
• un nuevo nombre y orientación para la Característica Especial 2.

El nombre actualizado para la Característica Especial 2 es “Identificar dispositivos en función de la información solicitada activamente.” La orientación de la política cubre explícitamente características recopiladas a través de JavaScript o API, como fuentes, resolución de pantalla y complementos, e información solicitada activamente a través de User-Agent Client Hints. Los usuarios deben optar por participar antes de que un proveedor utilice esta Característica Especial.

Por qué esto es más que una actualización de texto

Un CMP que codifica etiquetas de forma rígida o asume la antigua forma de GVL podría fallar incluso si el banner sigue viéndose normal. Los equipos de producto necesitan rastrear los nuevos datos desde la ingestión hasta cada capa de UI, etiqueta de accesibilidad, registro de proveedor en caché y prueba de regresión. El principio de diseño seguro es simple: renderizar el significado oficial con precisión, hacer que la presencia o ausencia de una elección de usuario sea inconfundible y no convertir una Característica explicativa en un interruptor falso.

El consentimiento multi-dispositivo necesita un alcance explícito

La Política v5.0.b añade un alcance multi-dispositivo a las definiciones del marco. Una base legal puede aplicarse a través de puntos de acceso para el mismo servicio o grupo; por ejemplo, un sitio web y una aplicación móvil utilizados por una cuenta autenticada, cuando la implementación apoya ese alcance. La capa inicial de la interfaz del marco debe informar al usuario si la elección de consentimiento es específica del servicio, específica del grupo y/o multi-dispositivo.

Esta conveniencia crea una responsabilidad del producto. Un CMP necesita una forma definida de resolver una elección hecha en un dispositivo antes del inicio de sesión contra preferencias ya almacenadas en la cuenta. También necesita mantener la negativa y la retirada tan utilizables como la aceptación en el mismo alcance.

La recomendación de CNIL de enero de 2026 sobre dispositivos cruzados es una guía regulatoria francesa en lugar de una regla TCF a nivel de la UE, pero es un punto de referencia útil para la implementación. CNIL recomienda que:

• aceptar, rechazar y retirar tengan el mismo alcance multi-dispositivo;
• se informe a los usuarios antes de elegir que la preferencia se aplicará a los dispositivos conectados a su cuenta;
• se muestre un breve recordatorio cuando el usuario inicie sesión en un nuevo dispositivo;
• los conflictos se manejen de manera transparente, priorizando la elección más reciente antes del inicio de sesión o la preferencia de la cuenta.

Documenta la regla de conflicto elegida y prueba ambas direcciones. Un almacén de preferencias técnicamente consistente aún puede crear una experiencia engañosa si no se informa a los usuarios cuál elección prevalece.

Qué cambios hay bajo el capó

El paquete técnico está programado para el 23 de julio, por lo que los equipos de implementación deben utilizar el material actual para prepararse, no para pretender que la diferencia final ya ha sido verificada. El resumen de comentarios públicos de IAB Tech Lab identifica dos áreas de ingeniería concretas.

Primero, la GVL gana el objeto standardTexts utilizado para explicaciones de Características. Los analizadores, tipos, cachés, API y código de renderizado necesitan aceptar y preservar el nuevo campo. Un retroceso elegante es útil para la resiliencia operativa, pero no debe omitir silenciosamente una divulgación requerida después de la fecha límite.

En segundo lugar, la vista previa elimina una solución para proveedores que declaran solo Propósitos Especiales. Dado que TCF v2.3 hizo obligatorio el segmento disclosedVendors, esos proveedores pueden determinar si fueron divulgados desde ese segmento. Por lo tanto, la vista previa elimina el requisito de colocar a los proveedores de Propósitos Especiales únicamente en la sección de Interés Legítimo del proveedor de la cadena TC.

Una regla de implementación cautelosa

Prepara pruebas ahora, luego vincula el comportamiento de producción al texto final v2.4 publicado el 23 de julio. En particular, compara la especificación final de la cadena TC, el material de la API de CMP, el esquema de GVL, las traducciones y los ejemplos con la vista previa. Registra la versión que probaste. “Seguimos el artículo de junio” no es un rastro de auditoría útil cuando existe una especificación final.

Una lista de verificación de preparación para TCF v2.4 de siete puntos

La fecha límite es más fácil de gestionar cuando cada requisito tiene un propietario y una prueba de aceptación observable. Comienza con esta lista de verificación y amplíala para tu arquitectura.

1. Inventario de cada superficie TCF. Enumera propiedades web, experiencias incrustadas, aplicaciones móviles, aplicaciones CTV, configuraciones de consentimiento, centros de preferencias de cuenta, SDK y consumidores de GVL en caché. Marca cada uno como web, aplicación o CTV para la planificación de fechas límite.
2. Compara la versión del 23 de julio. Compara la especificación final, el esquema de GVL, las traducciones, las ilustraciones y las referencias de políticas con tu implementación actual v2.3 y la vista previa de comentarios públicos.
3. Actualiza la ingestión de GVL. Verifica que standardTexts, ilustraciones, la Característica Especial 2 renombrada y futuros campos desconocidos sobrevivan al análisis, almacenamiento, API y caché.
4. Prueba la interfaz de usuario. Verifica que las explicaciones de las Características aparezcan junto a la información correcta, no se vean como controles, sean legibles con zoom y tecnología asistiva, y funcionen en cada idioma soportado. Revisa la experiencia del banner de cookies como un flujo completo en lugar de una sola primera capa.
5. Prueba la señalización. Crea fixtures para proveedores de Propósitos Especiales únicamente y verifica las reglas finales de codificación y decodificación v2.4 a través del CMP, proveedores descendentes y cualquier manejo de consentimiento del lado del servidor.
6. Define el comportamiento multi-dispositivo. Documenta el alcance, los requisitos de identidad, el almacenamiento, la propagación, la retirada y la regla utilizada cuando las elecciones de dispositivo y cuenta entran en conflicto. Prueba los caminos de aceptación, rechazo, cambio, cierre de sesión, nuevo dispositivo y eliminación de cuenta.
7. Publica y observa. Lanza cambios web antes del 23 de octubre con monitoreo para fallos de GVL, errores de cadena de consentimiento, divulgaciones faltantes y cambios inusuales en las tasas de elección. Mantén los lanzamientos de aplicaciones y CTV en un plan separado para el 23 de febrero de 2027.

La auto-alojamiento no elimina estas responsabilidades. Si operas OCI en tu propia infraestructura, controlas la ventana de actualización y puedes inspeccionar la implementación, pero también eres responsable de la revisión, implementación y verificación de la especificación final.

Qué deben preguntar los editores a su proveedor de CMP

Los editores no necesitan implementar cada cambio de analizador ellos mismos, pero no deben aceptar “listo para TCF” como una respuesta completa. Pide evidencia vinculada a tus entornos y fechas reales.

Las preguntas útiles incluyen:

• ¿Qué versiones de Políticas TCF y Especificaciones Técnicas están en producción hoy?
• ¿Cuándo estará disponible el soporte web para v2.4, y qué acción del cliente se requiere?
• ¿Cómo se renderizan y traducen las nuevas explicaciones de Características, ilustraciones y texto de la Característica Especial 2?
• ¿El producto admite el alcance multi-dispositivo, y cómo se resuelven exactamente las elecciones en conflicto?
• ¿Qué versiones de SDK web, aplicación y CTV contienen los cambios?
• ¿Qué pruebas automatizadas y manuales cubren el comportamiento final de la cadena TC v2.4?
• ¿Los usuarios necesitarán ver la interfaz del marco nuevamente, y cuál es la fuente de esa decisión?

Pide al proveedor que separe el cumplimiento del marco, la certificación de Google y el apoyo general a la ley de privacidad. Se superponen, pero ninguno es prueba del otro. Tus propias obligaciones como controlador, editor y proveedor aún necesitan una evaluación de cumplimiento del GDPR adecuada al procesamiento que realizas.

Qué no significa TCF v2.4

TCF v2.4 es una actualización del marco de la industria, no un nuevo estatuto y no un mandato universal para cada sitio web. La propia política de IAB Europe describe la participación como voluntaria y dice que el marco no es un sustituto de que los participantes individuales asuman la responsabilidad de sus obligaciones legales.

Mantén estos límites visibles en la comunicación interna y con los clientes:

• cumplir con la fecha límite del TCF no hace que un flujo de consentimiento sea legal por sí mismo;
• la certificación de CMP de Google no equivale a un cumplimiento total con el TCF o la ley de privacidad;
• una cadena TC técnicamente válida no prueba que el usuario haya recibido información clara o haya tomado una elección válida;
• la conveniencia multi-dispositivo no justifica un alcance oculto o una propagación unilateral;
• una nueva etiqueta estándar no corrige una interfaz engañosa a su alrededor.

Utiliza asesoría legal para conclusiones específicas de la jurisdicción. Utiliza la especificación, la política y la orientación del regulador como entradas separadas para los requisitos del producto en lugar de fusionarlas en un ticket vago de “cumplimiento”.

Preguntas frecuentes

¿Qué significa IAB TCF?

IAB TCF significa el Marco de Transparencia y Consentimiento de IAB Europe. Estandariza cómo los editores, CMP y proveedores participantes divulgan el procesamiento de datos, capturan elecciones relevantes y comunican señales de consentimiento, objeción y transparencia en el ecosistema de publicidad digital.

¿Qué es IAB TCF v2 3?

TCF v2.3 es la versión técnica inmediatamente anterior a v2.4. Entre otros cambios, hizo obligatorio el segmento disclosedVendors. Eso es importante para v2.4 porque el borrador de comentarios públicos utiliza el segmento obligatorio para eliminar la antigua solución de interés legítimo para proveedores que solo tienen Propósitos Especiales.

¿Qué es la lista TCF?

El término generalmente se refiere a la Lista Global de Proveedores, o GVL. IAB Europe la mantiene para proveedores TCF registrados, y los CMP utilizan sus declaraciones, texto estándar y datos relacionados para presentar información y producir señales del marco. El lanzamiento de v2.4 incluye una actualización correspondiente de la GVL programada para el 23 de julio de 2026.

¿Cada CMP necesita implementar TCF v2.4?

No. Las fechas límite conciernen a los CMP y las instalaciones en vivo que participan en el TCF de IAB Europe. Una herramienta de consentimiento no TCF aún puede tener obligaciones bajo la ley de privacidad o la política de la plataforma, pero esas obligaciones no la convierten automáticamente en un participante del TCF.

¿Cuál es la fecha límite de TCF v2.4 para los CMP?

La fecha límite confirmada es el 23 de octubre de 2026 para entornos web y el 23 de febrero de 2027 para entornos de aplicaciones móviles y CTV. Las especificaciones y la actualización correspondiente de la GVL están programadas para su publicación el 23 de julio de 2026.

Conclusión

TCF v2.4 no es una razón para rediseñar cada flujo de consentimiento. Es una razón para verificar las partes en las que confían los usuarios y proveedores: explicaciones claras de Características, alcance honesto, elecciones reversibles entre dispositivos y señales precisas. Comienza con los archivos del 23 de julio, prueba la web antes del 23 de octubre y mantén móvil y CTV en el plan de febrero de 2027. Un lanzamiento documentado y basado en evidencia superará una actualización apresurada solo de banner.