Quando o Cade vira protagonista de uma decisão que envolve IA e conteúdo jornalístico, eu presto atenção. Não é só briga de gigante — é o tipo de precedente que redefine como devs e empresas de tech tratam dados alheios. Segundo o Olhar Digital, a Superintendência-Geral do Cade rejeitou um pedido do Google para apresentar provas testemunhais numa investigação sobre o uso de conteúdo jornalístico sem remuneração aos veículos de mídia. O caso agora inclui IA generativa no escopo, e isso muda tudo para quem constrói produtos baseados em LLM.
O que o Cade decidiu — e por que devs deveriam se importar
O processo original foi instaurado em 2019, mas ganhou novo fôlego em abril de 2026, quando o tribunal do Cade decidiu aprofundar a investigação para incluir a IA generativa no radar. A pergunta central é direta: quando um modelo de linguagem é treinado com conteúdo de jornais, quem paga a conta?
Na prática, o Google queria ouvir testemunhas para se defender, mas esqueceu de informar a qualificação completa de até três testemunhas na peça de defesa. O superintendente Felipe Roquete bateu o martelo: pedido prejudicado. O Cade aceitou apenas provas documentais, pareceres, análises econômicas e laudos periciais.
Esse detalhe burocrático parece menor, mas é revelador. Mostra que o regulador está pegando pesado com formalidades processuais — e quem opera nessa fronteira regulatória precisa ter documentação impecável. Se uma empresa com o aparato jurídico do Google tropeça nesse tipo de exigência, imagine o que acontece com startups e times pequenos.
O impacto técnico real: treino de LLMs e dados jornalísticos
Se você treina ou faz fine-tune de modelos, sabe que datasets de qualidade são caros. Jornais como Folha, Estadão, NYT e Wall Street Journal representam corpus textuais de altíssima qualidade — gramática impecável, factualidade verificada, diversidade de estilos e atualizações constantes.
O problema? Grande parte desses dados foram coletados via web scraping massivo, sem licenciamento explícito. O caso do Cade é só a ponta do iceberg — processos similares já rolam nos EUA (New York Times vs. OpenAI) e na Europa, com decisões pesadas emergindo em 2024 e 2025.
Para devs, a mensagem é clara: a era do “raspa tudo e treina em silêncio” está acabando. Quem quer construir produtos sérios precisa pensar em licenciamento desde o desenho da arquitetura de dados — não depois, quando o produto já estiver no ar e o jurídico bater na porta.
Na Prática: como respeitar robots.txt e licenciar dados de forma ética
Vou te mostrar um snippet que uso em projetos de coleta de dados. Não é só sobre ser bonzinho — é sobre sobreviver a uma auditoria jurídica. Esse padrão deveria ser o mínimo em qualquer pipeline de dados.
import requests
from urllib.robotparser import RobotFileParser
from urllib.parse import urlparse
import time
class EthicalScraper:
def __init__(self, base_url, user_agent="Mozilla/5.0 (compatible; MyBot/1.0)"):
self.base_url = base_url
self.user_agent = user_agent
self.rp = RobotFileParser()
self.rp.set_url(f"{base_url}/robots.txt")
self.rp.read()
def can_fetch(self, path):
"""Verifica se o robots.txt permite scraping do path"""
return self.rp.can_fetch(self.user_agent, path)
def fetch_with_rate_limit(self, url, delay=2):
"""Coleta com rate limiting respeitoso"""
parsed = urlparse(url)
if not self.can_fetch(parsed.path):
raise PermissionError(f"robots.txt bloqueia {parsed.path}")
time.sleep(delay) # Respeita o servidor alvo
response = requests.get(url, headers={"User-Agent": self.user_agent})
response.raise_for_status()
return response.text
# Uso correto em produção
scraper = EthicalScraper("https://exemplo-jornal.com.br")
try:
html = scraper.fetch_with_rate_limit("https://exemplo-jornal.com.br/artigo/123")
except PermissionError as e:
print(f"Bloqueado por robots.txt: {e}")
Esse padrão parece óbvio, mas a maioria dos scrapers que vejo em produção ignora completamente o robots.txt. Quando o Cade ou um juiz perguntar “como você coletou esses dados?”, a resposta “eu não verifiquei” é um desastre legal — e ético.
Erros Comuns que devs cometem em projetos com LLMs
Depois de revisar dezenas de projetos nos últimos anos, compilei os equívocos mais frequentes que vejo em times de desenvolvimento:
- Treinar sem documentar a origem dos dados. Se você não sabe de onde veio o corpus, não tem como defender uso legítimo. Documentação de provenance é tão importante quanto o modelo em si.
- Ignorar licenças Creative Commons e Terms of Service. Só porque está público não significa que é livre para uso comercial. CC-BY-SA exige atribuição; muitos termos de serviço proíbem scraping para treino.
- Fine-tunar com dados de clientes sem contrato explícito. LGPD, GDPR e agora decisões como a do Cade tornam isso um risco existencial para o produto.
- Não implementar rate limiting em scrapers. Além de antiético, derruba o servidor alvo, gera banimentos em massa e chama atenção indesejada.
- Confundir “fair use” americano com legislação brasileira. Aqui vale o que está na lei e o que o Cade interpreta — são universos regulatórios completamente diferentes.
A armadilha do fine-tuning “inocente”
Recebo muitas perguntas sobre como fazer fine-tune de modelos com dados de domínio específico. O fluxo típico é: pegar documentos internos da empresa, artigos públicos, PDFs de manuais técnicos, e jogar tudo no pipeline de treino. Funciona tecnicamente — o modelo melhora, a equipe comemora. Juridicamente? Pode ser um desastre esperando para acontecer.
Se sua empresa tem 500 funcionários e cada um alimenta o LLM interno com artigos de jornal que a empresa assina, você tem um problema em potencial. O conteúdo está licenciado para leitura humana, não para ingestão por máquina e posterior redistribuição em outputs gerados.
Alternativas reais para devs que precisam de dados textuais de qualidade
Antes de sair raspando a internet sem critério, considere estas fontes legítimas que funcionam em produção:
- Common Crawl — dataset massivo com licenciamento explícito e filtros de qualidade. É a base de muitos modelos abertos, mas sempre verifique os filtros aplicados.
- Hugging Face Datasets — repositório curado com licenças claras. Verifique sempre a licença de cada dataset individualmente antes de usar.
- Wikipedia + Wikimedia APIs — licença CC BY-SA, uso comercial permitido com atribuição. Excelente para factualidade.
- Licenciamento direto com veículos — NYT, Reuters, AP e outros vendem acesso programático a seus acervos. É a opção mais segura.
- APIs oficiais de news — NewsAPI, GDELT e similares operam dentro de frameworks legais bem definidos.
Se o orçamento permitir, licenciamento direto é o caminho mais seguro. É caro, mas elimina 99% do risco regulatório. Para startups em fase inicial, APIs oficiais com bom plano de rate limit resolvem a maioria dos casos.
Por que essa decisão do Cade é um divisor de águas
Não é exagero dizer que estamos vendo a formação de uma nova jurisprudência global sobre IA e propriedade intelectual. O caso do Cade brasileiro, somado ao New York Times vs. OpenAI, ao GDPR europeu e às recentes decisões chinesas, está criando um mosaico regulatório complexo que nenhum dev pode ignorar.
Para quem desenvolve, isso significa uma mudança cultural profunda: compliance não é mais coisa só do DPO. É parte do código. Quem ignora, vai descobrir tarde demais que o produto que levou dois anos para construir não pode ser vendido em metade do mundo — ou que recebeu uma notificação extrajudicial de um conglomerado de mídia.
FAQ — Perguntas que devs realmente fazem
1. Posso treinar um LLM com artigos de jornal que estão publicamente acessíveis?
Tecnicamente, sim. Juridicamente, depende da jurisdição e dos termos de uso do site. No Brasil, o Cade está sinalizando que vai exigir remuneração. Nos EUA, o fair use ainda é debatido em cortes. Minha recomendação: trate como se a resposta fosse “não” até ter parecer jurídico formal.
2. O que muda na prática com a inclusão de IA generativa no escopo do Cade?
Muda o objeto da investigação. Antes, era focado em uso de conteúdo em snippets e resultados de busca. Agora, inclui especificamente o uso em treino de modelos generativos — o que pode gerar sanções mais pesadas, porque o dano potencial é maior e mais difuso.
3. Como verificar se um dataset é seguro para uso comercial?
Verifique três coisas: a licença explícita do dataset (arquivo LICENSE ou metadata), a origem dos dados (se foram coletados de fontes com permissão), e os termos de serviço das APIs usadas na coleta. Na dúvida, consulte um advogado especializado em propriedade intelectual antes de colocar em produção.
4. Web scraping é ilegal no Brasil?
Não é ilegal em si, mas tem limites claros. O STJ já decidiu que scraping de dados publicamente acessíveis pode ser permitido, desde que respeite a finalidade, não sobrecarregue o servidor e não viole direitos autorais. Usar para treino de IA comercial é território cinzento — e cada vez menos cinzento, como o Cade está demonstrando.
5. Vale a pena investir em RAG com fontes licenciadas em vez de fine-tuning?
Depende do caso de uso. RAG (Retrieval-Augmented Generation) é geralmente mais barato e juridicamente mais seguro, porque você não treina nada — só consulta fontes em tempo real. Para a maioria das aplicações empresariais, RAG resolve muito bem. Fine-tuning vale quando você precisa de comportamento de modelo específico que não dá para obter via prompt engineering.
O que eu recomendo na prática
Se você está começando um projeto com LLMs hoje, minha sugestão é direta:
- Mapeie todas as fontes de dados que pretende usar antes de escrever a primeira linha de código de treino.
- Documente licenças e termos de uso de cada fonte em um arquivo
DATA_PROVENANCE.mdno repositório. - Prefira APIs oficiais e datasets com licença explícita sempre que possível.
- Implemente rate limiting e respeito ao robots.txt desde o primeiro commit — não como “nice to have”.
- Considere RAG com fontes licenciadas antes de partir para fine-tuning.
- Mantenha um registro de auditoria de dados — quem vai perguntar vai querer ver.
Compliance não trava inovação. O que trava é o que acontece quando você ignora compliance e leva um processo de bilhões. O Cade já mostrou que está disposto a pegar pesado em formalidades. O Google, com toda a estrutura jurídica que tem, acabou perdendo um pedido por esquecer de qualificar testemunhas na peça processual.
Se você é dev independente ou trabalha numa startup sem departamento jurídico robusto, não tem a mesma folga que o Google. Faça o dever de casa desde o início — vai poupar muita dor de cabeça no futuro.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.