Resposta rápida: IAB Europe publicou TCF 2.4 em 23 de julho de 2026. Implementações web devem ser migradas até 23 de outubro de 2026; para aplicativos móveis e CTV, o prazo é 23 de fevereiro de 2027. A versão de formato do TC string permanece 2 e a versão de política TCF permanece 5. TCF 2.4 não introduz, portanto, um novo formato de string em geral. O crucial são as diretrizes atualizadas, particularmente o tratamento mais rigoroso do interesse legítimo dos fornecedores.
O Essencial
- TCF 2.4 é a especificação atual; o prazo de migração é separado por ambiente.
- Web: 23 de outubro de 2026. Aplicativo móvel e CTV: 23 de fevereiro de 2027.
- A versão binária do TC string permanece 2;
tcfPolicyVersionpermanece 5. - Consentimentos já válidos não exigem automaticamente novo consentimento apenas pela mudança de número de versão. Uma nova solicitação pode ser necessária por outros motivos, como alterações em fornecedores, finalidades ou textos legais.
- O segmento
DisclosedVendorstornou-se obrigatório com TCF 2.3 e continua em 2.4. Não é uma nova funcionalidade 2.4. - Fornecedores não podem sinalizar interesse legítimo apenas com base em Special Purposes. Esta regra 2.4 já se aplica desde abril de 2026.
- Registro e certificação são afirmações diferentes. Verifique também para qual ambiente uma CMP está registrada.
O que muda com IAB TCF 2.4?
TCF 2.4 atualiza as diretrizes e especificações técnicas do Transparency and Consent Framework. Para implementadores, é particularmente importante não confundir números de versão com campos no TC string: o segmento Core continua usando versão de formato 2, e a versão de política permanece 5. Integrações não devem, portanto, codificar uma versão de string inventada "2.4" nem descartar todos os sinais existentes apenas por causa da mudança de versão.
A mudança praticamente mais importante diz respeito ao Vendor Legitimate Interest. Um fornecedor pode definir um bit LI apenas se houver pelo menos uma finalidade de processamento permitida para isso. Special Purposes sozinhos não são suficientes. CMPs devem impor essa invariante ao gerar, restaurar e revogar sinais.
Disclosed Vendors: introduzido em 2.3, ainda obrigatório em 2.4
O segmento DisclosedVendors documenta quais fornecedores foram realmente mostrados à pessoa. Tornou-se obrigatório com TCF 2.3 e permanece parte de uma implementação correta de 2.4. Ao migrar para 2.4, o segmento não deve ser reinventado, mas verificado em relação à lista de fornecedores visível:
- Cada fornecedor contido no segmento deve ter sido divulgado na interface de consentimento.
- Fornecedores não exibidos, excluídos ou inativos não devem ser sinalizados como divulgados.
- O conjunto de fornecedores em configuração, interface,
DisclosedVendorseTCDatadeve ser logicamente consistente.
Prazos por Ambiente
| Ambiente | Prazo de migração para TCF 2.4 |
|---|---|
| Web | 23 de outubro de 2026 |
| Aplicativo móvel | 23 de fevereiro de 2027 |
| CTV | 23 de fevereiro de 2027 |
Um registro web não cobre automaticamente aplicativos móveis ou CTV. Verifique a entrada da CMP na lista oficial de CMPs e os ambientes listados lá. Biscotti CMP é operada pela Campcruisers GmbH e está registrada com CMP-ID 497 para Web. Um registro para aplicativo nativo ou CTV não é, portanto, afirmado.
Migração Gradual para TCF 2.4
1. Verificar status de registro e ambiente
Compare CMP-ID, entidade legal e ambientes registrados com a lista oficial de CMPs. Não confie em um logo ou formulação geral como "compatível com IAB".
2. Vincular GVL atual e seleção de fornecedor
Carregue uma Global Vendor List atual e determine os fornecedores que são realmente usados no site ou aplicativo específico. A interface e o status de consentimento gerado devem ser derivados do mesmo conjunto de fornecedores.
3. Implementar regra Vendor-LI fail-closed
Não gere um sinal Vendor-LI se o fornecedor declarar apenas Special Purposes ou nenhuma finalidade LI permitida permanecer. Verifique esta regra também após Reject, revogação, mudança de GVL e restauração de um estado salvo.
4. Manter semântica do TC string
Continue codificando versão de formato TC string 2 e versão de política 5. Mantenha o segmento obrigatório DisclosedVendors. Não altere campos de versão de API apenas porque a especificação do Framework é chamada 2.4.
5. Decidir sobre Reconsent de forma direcionada
Uma mudança de versão por si só não é motivo para Reconsent automático. Em vez disso, verifique se as finalidades, fornecedores, bases legais, Publisher Restrictions ou as informações mostradas à pessoa mudaram substancialmente. Documente a decisão.
6. Testar transições de estado completas
Teste pelo menos Accept All, Reject All, seleção granular, interesse legítimo, revogação, reabertura, reinicialização do navegador e uma atualização de GVL. Decodifique os strings gerados independentemente e compare conjuntos de fornecedores e finalidades.
Lista de Verificação Técnica
__tcfapi('ping', 2, ...)relata dados de CMP e política consistentes.- Versão de formato do TC string é 2 e
tcfPolicyVersioné 5. DisclosedVendorscorresponde à lista de fornecedores realmente visível.- Vendor-LI nunca é definido sem uma finalidade LI permitida.
- Reject e revogação removem sinais de consentimento e LI não permitidos.
- Estados salvos são aceitos apenas se corresponderem à configuração atual.
- CMP-ID e ambiente registrado correspondem à lista pública de CMPs.
- Versões web, aplicativo móvel e CTV são lançadas separadamente.
Usuários existentes precisam ser consultados novamente?
Não automaticamente. A designação de versão TCF 2.4 não altera nem o formato do TC string por si só nem o número de versão de política. No entanto, novo consentimento é necessário se a decisão anterior não refletir mais adequadamente o processamento atual ou se a pessoa precisar receber novas informações substanciais. A decisão deve ser tomada com base na mudança de configuração real e com consultoria legal.
Erros Comuns
- Codificar TCF 2.4 como nova versão de formato TC string.
- Aumentar
tcfPolicyVersionsem base normativa. - Descrever incorretamente Disclosed Vendors como nova mudança 2.4.
- Tratar Special Purposes como base suficiente para Vendor-LI.
- Representar um registro web como registro de aplicativo móvel ou CTV.
- Usar "registrado", "validado" e "certificado" como sinônimos.
- Testar apenas o caminho Accept All e omitir Reject, revogação ou reinicialização.
Conclusão
A migração para TCF 2.4 não é apenas uma mudança de texto. Requer um lançamento planejado por ambiente, sinais Vendor-LI corretos e prova de que fornecedores visíveis, estado salvo e TC string são consistentes. Quem distinguir corretamente versão de formato 2, versão de política 5 e o histórico de Disclosed Vendors evita os erros de migração mais comuns.
FAQ
TCF 2.4 é uma nova versão de formato TC string?
Não. O campo de versão do TC string permanece 2; a versão do Framework 2.4 não deve ser escrita neste campo.
A versão de política TCF muda?
Não. Para TCF 2.4, tcfPolicyVersion permanece em 5.
Disclosed Vendors são novos em TCF 2.4?
Não. O segmento tornou-se obrigatório com TCF 2.3 e continua em 2.4.
TCF 2.4 sempre requer Reconsent?
Não. O que importa são as mudanças reais no processamento e informação do usuário, não apenas o número de versão.
Biscotti CMP está registrada para aplicativos móveis ou CTV?
O registro atual da Campcruisers GmbH, CMP-ID 497, cobre Web. Isso não implica registro para aplicativos móveis ou CTV.
Fontes
- IAB Europe, TCF Policies v5.0.b e Specifications v2.4: https://iabeurope.eu/transparency-consent-framework/
- IAB Europe, lista de CMPs: https://cmplist.consensu.org/v2/cmp-list.json
- IAB Tech Lab, Consent String and Vendor List Formats: https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework
Este artigo explica aspectos técnicos e organizacionais e não constitui aconselhamento jurídico.