South Summit Brazil 2026: regulação não acompanha tecnologia e RevOps vira terra de ninguém?

O elefante na sala da South Summit Brazil 2026

Sua equipe de RevOps implementou scoring preditivo com IA. O modelo classifica leads automaticamente, enriquece dados a partir de fontes externas, dispara sequências personalizadas e até sugere o melhor momento para o SDR ligar. Tudo funcionando. Pipeline acelerando. Os números no dashboard nunca estiveram tão verdes.

Até que alguém faz a pergunta que ninguém queria ouvir: "Nós temos base legal para fazer tudo isso?"

Essa é a tensão que permeou — explícita ou implicitamente — boa parte das discussões na South Summit Brazil 2026, realizada em Porto Alegre neste mês de março. O evento, que se consolidou como o principal encontro de inovação e empreendedorismo da América Latina, trouxe mais de 25 mil participantes e centenas de painéis. Mas o tema subjacente a quase tudo foi o mesmo: a tecnologia está avançando numa velocidade que a regulação simplesmente não consegue acompanhar.

E enquanto founders, VCs e executivos de tecnologia discutem isso como uma questão macro — filosoficamente interessante, vagamente preocupante — para quem opera a máquina de receita de uma empresa, isso é um problema concreto e imediato. Porque RevOps é, por definição, a área que orquestra dados, automações e processos entre Marketing, Vendas e Customer Success. E é exatamente nessa orquestração que o gap regulatório se materializa em riscos reais.

Quando a regulação não diz claramente o que pode e o que não pode, quem opera RevOps precisa decidir sozinho. E essa decisão tem consequências financeiras, legais e reputacionais.

O que de fato foi discutido — e o que ficou nas entrelinhas

A South Summit Brazil 2026 teve uma programação diversa, cobrindo desde deep tech até impacto social. Mas três temas dominaram os palcos principais e têm relação direta com quem trabalha com operações de receita:

1. IA generativa e o novo ciclo de automação

Múltiplos painéis exploraram como a IA generativa está sendo aplicada em vendas, atendimento e marketing. Desde chatbots que conduzem conversas inteiras de qualificação até modelos que geram propostas comerciais personalizadas em segundos. O tom geral foi de otimismo — mas com ressalvas significativas sobre governança de dados. Como discutimos em detalhe no artigo sobre IA generativa em RevOps: o que funciona e o que é hype, separar aplicações reais de promessas vazias é essencial.

2. Regulação de IA: o vácuo legislativo brasileiro

Enquanto a União Europeia já implementa o AI Act e os Estados Unidos avançam com executive orders e regulações setoriais, o Brasil ainda discute seu marco regulatório de inteligência artificial. O PL 2338/2023, que propõe a regulamentação da IA no país, continua em tramitação. Painelistas destacaram que empresas brasileiras operam num limbo: a LGPD existe e é aplicável, mas não foi desenhada para lidar com as nuances de modelos preditivos, enriquecimento automatizado de dados e decisões algorítmicas que afetam o consumidor.

3. Dados como ativo — e como risco

Várias sessões abordaram a crescente importância dos dados como diferencial competitivo. Mas também surgiram discussões sobre o risco de tratar dados de leads e clientes como commodity. A pergunta que ecoou: se os dados são o novo petróleo, quem fiscaliza a refinaria?

O gap regulatório não é abstrato: ele chega no seu CRM

Vamos sair da teoria e entrar no concreto. Quando falamos de "gap regulatório em tecnologia", a tendência é pensar em grandes questões filosóficas sobre IA e sociedade. Mas para quem trabalha com RevOps, o problema é muito mais tangível do que parece.

Considere estas situações — todas comuns em operações de receita:

• Enriquecimento de dados via terceiros: Sua equipe usa uma ferramenta como Clearbit, Apollo ou ZoomInfo para enriquecer contatos no CRM com informações como cargo, empresa, receita estimada e número de funcionários. Esses dados são coletados automaticamente de fontes públicas e proprietárias. O lead não deu consentimento explícito para que você tenha essas informações. Isso viola a LGPD? Depende da interpretação — e é exatamente esse "depende" que é o problema.
• Scoring preditivo com IA: Um modelo de machine learning analisa o comportamento de todos os leads no seu funil e atribui uma probabilidade de conversão. Esse modelo, em algum nível, está tomando decisões automatizadas que afetam quais leads recebem atenção humana e quais são negligenciados. Sob a LGPD e o AI Act europeu, decisões automatizadas que afetam significativamente os titulares de dados exigem transparência e possibilidade de contestação. Seu modelo de scoring oferece isso?
• Sequências de e-mail automatizadas com personalização por IA: A IA gera o corpo do e-mail usando dados do CRM — histórico de interações, páginas visitadas, conteúdos baixados. O e-mail parece ter sido escrito por uma pessoa, mas não foi. Isso configura prática enganosa? Alguns reguladores já sinalizaram que sim.
• Integração de dados entre ferramentas: Seus dados fluem entre CRM, plataforma de automação de marketing, ferramenta de CS, sistema de billing e mais 4-5 ferramentas — como discutimos no artigo sobre o stack de RevOps enxuto. Cada integração é uma transferência de dados pessoais. Cada transferência precisa de base legal. Você mapeou todas?

Nenhuma dessas situações tem uma resposta regulatória clara e definitiva no Brasil em março de 2026. E esse é precisamente o ponto.

O gap regulatório não é um problema para "depois". É um problema que já está embutido no seu stack, nos seus workflows e no seu pipeline. Você só ainda não percebeu — ou está escolhendo não olhar.

Mapa de impacto: onde a falta de regulação atinge RevOps

Para tornar isso mais concreto, mapeei os pontos de contato entre o gap regulatório e as três grandes áreas que RevOps orquestra. O que você vai ver não é uma análise jurídica — é uma análise operacional. A pergunta não é "isso é legal?" e sim "o que acontece com minha operação se amanhã decidirem que isso não é legal?".

Perceba: não estou dizendo que essas práticas são ilegais. Estou dizendo que ninguém sabe com certeza se são ou não. E essa incerteza é, por si só, um risco operacional.

Framework GUARD: governança autônoma de receita em território sem lei

Se a regulação não dá respostas claras, a operação precisa criar suas próprias guardrails. Não como substituto da lei — mas como camada de proteção até que a lei chegue. Proponho o Framework GUARD: cinco princípios para operar RevOps com responsabilidade em um ambiente regulatório ambíguo.

Vamos detalhar cada princípio:

G — Governança de dados por padrão

A ideia é simples: opere como se a regulação mais restritiva já estivesse em vigor. Se o AI Act europeu exige transparência em decisões automatizadas, implemente transparência — mesmo que sua empresa opere apenas no Brasil e a lei local ainda não exija.

Por quê? Primeiro, porque se você vende para empresas europeias (mesmo que sejam filiais no Brasil), o AI Act já se aplica. Segundo, porque quando a regulação brasileira chegar, é muito mais fácil relaxar restrições do que implementá-las correndo. Terceiro, porque clientes B2B estão cada vez mais exigindo compliance dos fornecedores — independente de lei.

Na prática, isso significa: mapeie toda a coleta de dados no CRM, documente as bases legais, implemente consentimento granular. Se você usa a HubSpot, por exemplo, explore as funcionalidades de gerenciamento de consentimento e as bases legais por tipo de comunicação — como detalhamos em nosso guia de implementação de CRM, esse mapeamento deveria fazer parte do projeto desde o dia zero.

U — Uso documentado de cada automação

Quantos workflows estão rodando no seu CRM agora? Vinte? Cinquenta? Duzentos? E quantos deles você consegue explicar — não o que fazem tecnicamente, mas por que existem e que decisão de negócio suportam?

A prática de documentar cada automação não é apenas boa governança — é proteção. Se um regulador perguntar "por que vocês enviam essa sequência de e-mails automaticamente para leads que visitaram a página X?", a resposta precisa ser melhor do que "porque o marketing pediu".

Recomendo criar um registro de automações que inclua: nome do workflow, propósito de negócio, dados utilizados, decisão automatizada envolvida, responsável pela manutenção e data da última revisão.

A — Auditabilidade de decisões algorítmicas

Este é talvez o ponto mais crítico. Se seu lead scoring usa IA preditiva, você consegue explicar por que o Lead A recebeu score 92 e o Lead B recebeu score 34? Se seu health score de cliente determina que a Empresa C não merece atenção proativa do time de CS, você consegue demonstrar que isso não é discriminação algorítmica?

A auditabilidade não precisa ser perfeita. Não estamos falando de explicabilidade total de modelos de deep learning. Mas precisa ser razoável: quais variáveis entram, quais têm maior peso, como o modelo foi treinado, com que frequência é recalibrado. Isso é o mínimo.

R — Revisão periódica do stack e dos fluxos

O cenário regulatório muda. Interpretações jurídicas evoluem. Ferramentas atualizam seus termos de uso. O que era uma integração inofensiva há seis meses pode ter se tornado uma transferência internacional de dados problemática depois que o fornecedor mudou seus servidores de região.

Proponho uma revisão trimestral que cubra: todas as integrações ativas no stack (de onde vêm os dados, para onde vão), todos os fornecedores de enriquecimento de dados, todos os modelos de scoring e priorização, e todos os workflows com lógica condicional que afeta a experiência do lead/cliente.

D — Design de opt-out em cada camada

Este princípio é estrategicamente inteligente porque serve a dois propósitos ao mesmo tempo: compliance E experiência do cliente.

Se um lead recebe um e-mail automatizado e quer sair da sequência, ele consegue? Se um cliente descobre que está recebendo menos atenção do CS porque seu health score é baixo, ele pode contestar? Se um prospect quer saber por que foi classificado como "baixa prioridade" no pipeline, existe um canal para isso?

Implementar opt-out em cada camada não é fraqueza — é maturidade operacional. E na prática, as ferramentas modernas de CRM já oferecem boa parte dessa infraestrutura. É questão de ativar e configurar corretamente.

Case estudo: quando a automação ultrapassou a compliance

Imagine uma empresa de software B2B, especializada em soluções de gestão financeira para médias empresas. Faturamento anual de R$ 25 milhões. Time de 120 pessoas, sendo 8 em Marketing, 15 em Vendas e 6 em CS. Um analista de RevOps orquestrando tudo.

Em meados de 2025, a diretoria decidiu apostar pesado em automação e IA para escalar a operação comercial sem aumentar headcount. O investimento foi significativo: R$ 380.000 entre ferramentas de IA, integrações e consultoria de implementação.

O resultado operacional foi impressionante nos primeiros seis meses:

• Volume de leads qualificados aumentou 45% com enriquecimento automatizado via três fornecedores de dados diferentes.
• Tempo médio de resposta a MQLs caiu de 4 horas para 8 minutos, com sequências disparadas automaticamente — processo similar ao que descrevemos no artigo sobre handoff Marketing → Vendas com workflows e SLAs.
• O scoring preditivo com IA passou a priorizar o pipeline com uma precisão de 72% (acima dos 55% do scoring manual anterior).
• A equipe de CS implementou health scores automatizados que determinavam qual gerente de conta recebia cada caso e com que frequência o contato proativo acontecia.

Os dashboards estavam verdes. O pipeline estava gordo. O pipeline coverage ratio era de 4,2x. A diretoria estava comemorando.

Até que três coisas aconteceram quase simultaneamente:

1. Um prospect grande respondeu um e-mail automatizado com: "Vocês estão usando meus dados sem minha autorização. Meu jurídico vai entrar em contato." A empresa havia enriquecido o contato com dados de uma ferramenta de terceiros e disparado uma sequência personalizada citando informações que o prospect nunca havia fornecido diretamente.
2. Um cliente de ticket médio elevado descobriu que estava recebendo atendimento de "segundo escalão" porque o health score automatizado havia classificado sua conta como baixo risco de churn — interpretando incorretamente a ausência de tickets de suporte como satisfação, quando na verdade o cliente havia simplesmente desistido de pedir ajuda.
3. Uma auditoria interna de segurança descobriu que os dados fluíam entre 9 ferramentas diferentes, com três integrações passando dados pessoais para servidores fora do Brasil, sem cláusulas contratuais adequadas de transferência internacional de dados.

O resultado? A empresa precisou pausar 60% das automações por três meses enquanto reestruturava a operação. O pipeline, que estava em 4,2x, caiu para 1,8x enquanto as sequências estavam paradas. O deal cycle médio aumentou de 45 para 72 dias — exatamente o tipo de vazamento invisível no deal cycle que métricas padrão não capturam até ser tarde demais.

O custo total da "pausa forçada": estimado em R$ 1,2 milhão entre receita perdida, horas de retrabalho jurídico e reestruturação de processos.

A automação não foi o problema. O problema foi automatizar sem criar uma camada de governança. A velocidade superou a responsabilidade — e quando o gap regulatório se materializou, não havia rede de proteção.

Quando a empresa retomou as operações, fez diferente. Aplicou princípios similares ao Framework GUARD: documentou todas as automações, implementou opt-out em cada camada, criou um registro de base legal por fonte de dados e reduziu o número de ferramentas de enriquecimento de três para uma — com contrato revisado pelo jurídico.

Seis meses depois da reestruturação, o pipeline não voltou a 4,2x — estabilizou em 3,1x. Mas a taxa de conversão subiu de 18% para 26%, porque os leads que entravam tinham dados limpos e consentimento documentado. O resultado líquido? Receita 12% maior do que no período anterior ao incidente.

O contexto brasileiro: LGPD, IA Act europeia e o limbo regulatório

Para contextualizar adequadamente a discussão que animou a South Summit, vale entender onde cada peça regulatória se encaixa — e onde estão os buracos.

A LGPD: poderosa, mas insuficiente para IA em RevOps

A LGPD (Lei Geral de Proteção de Dados) é, sem dúvida, uma legislação robusta. Ela estabelece bases legais para tratamento de dados, direitos dos titulares, e penalidades significativas (até 2% do faturamento, limitado a R$ 50 milhões por infração). Mas ela foi pensada primariamente para proteger dados pessoais — não para regular decisões algorítmicas, modelos preditivos ou IA generativa.

A ANPD (Autoridade Nacional de Proteção de Dados) tem publicado guias e orientações sobre IA e dados pessoais, mas essas orientações são interpretativas — não têm força de lei. E a velocidade com que a tecnologia avança é incomparavelmente maior do que a velocidade com que guias regulatórios são publicados.

O AI Act europeu: referência, mas não lei aqui

O AI Act da União Europeia, que entrou em vigor progressivamente a partir de 2024, classifica sistemas de IA por nível de risco e impõe obrigações específicas para cada categoria. Para RevOps, os sistemas de scoring e priorização provavelmente se enquadrariam como "risco limitado" ou "risco alto", dependendo do contexto — especialmente se afetarem decisões sobre crédito, contratação ou acesso a serviços.

O AI Act não se aplica diretamente a empresas brasileiras — a menos que elas atendam clientes ou processem dados de cidadãos europeus. Mas serve como referência do que está por vir. E a tendência global é clara: regulações de IA estão convergindo para exigir transparência, auditabilidade e direito de contestação.

O PL brasileiro de IA: expectativa sem prazo

O marco regulatório de IA no Brasil continua em discussão. A expectativa é que eventualmente tenhamos uma legislação dedicada, mas o prazo é incerto. Isso significa que, por ora, empresas brasileiras operam com a LGPD (que não foi feita para isso) e com interpretações da ANPD (que podem mudar).

Para quem opera RevOps, a implicação prática é: você não pode esperar a regulação para se preparar. Quando ela chegar — e vai chegar — a adaptação retroativa será dolorosa e cara. As empresas que já operam com governança por design terão uma vantagem competitiva significativa.

E se a regulação chegar amanhã e invalidar o que construí?

Esta é a objeção mais legítima ao Framework GUARD e à abordagem de "regular a si mesmo". Se a regulação pode chegar a qualquer momento e ser diferente do que antecipamos, não estamos arriscando investir em governança para depois precisar refazer tudo?

Vamos abordar isso com honestidade:

Objeção 1: "Investir em governança agora é desperdício se a lei mudar"

Governança de dados e auditabilidade de processos nunca são desperdício. Mesmo que a regulação final seja diferente do que antecipamos, os princípios básicos — saber que dados você tem, de onde vieram, para que são usados e quem pode acessá-los — são universais. Nenhuma regulação razoável vai punir empresas por terem mais controle sobre seus dados.

O risco real é o oposto: não fazer nada e depois precisar retroagir. É o equivalente operacional de nunca fazer backup porque "meu HD nunca falhou". Quando falhar — e vai falhar — o custo é exponencialmente maior.

Objeção 2: "Isso vai desacelerar nossa operação"

Sim, no curto prazo. Documentar automações, revisar integrações, implementar opt-out — tudo isso consome tempo. Mas como vimos no case study, a empresa que operava no "modo rápido" acabou perdendo três meses inteiros de operação e R$ 1,2 milhão. O que é mais lento: gastar uma semana por trimestre em auditoria, ou parar tudo por 90 dias quando a crise estourar?

Além disso, a governança frequentemente revela redundâncias e ineficiências. Quando você é forçado a documentar cada automação, descobre que metade delas é desnecessária. O resultado paradoxal é que a operação fica mais enxuta.

Objeção 3: "Minha empresa é pequena demais para se preocupar com isso"

A LGPD se aplica a qualquer empresa que trate dados pessoais, independente do porte. E empresas menores, justamente por terem menos recursos para lidar com uma crise regulatória, são as que mais deveriam investir em prevenção. Uma multa de R$ 50 mil pode ser irrelevante para uma enterprise, mas pode inviabilizar uma startup.

E aqui entra um ponto que poucos consideram: clientes enterprise estão cada vez mais auditando fornecedores. Se você vende para grandes empresas e não consegue demonstrar governança de dados, pode perder negócios não por questão regulatória direta, mas por exigência contratual do comprador.

Objeção 4: "A concorrência não está fazendo nada disso"

Provavelmente não. E provavelmente vai pagar por isso. O fato de a concorrência operar sem governança não torna essa prática segura — torna a oportunidade de diferenciação maior. Quando a regulação chegar (e, novamente, vai chegar), quem já estiver preparado terá uma vantagem competitiva real: operação contínua enquanto os concorrentes pausam para se adaptar.

O que fazer agora: um checklist para times de RevOps

Sair de um evento como a South Summit com insights é fácil. O difícil é traduzir esses insights em ações concretas. Aqui vai um checklist pragmático para aplicar nas próximas semanas:

Semana 1: Mapeamento

1. Liste todas as ferramentas no seu stack de RevOps — de CRM a enriquecimento de dados, automação de marketing, ferramenta de sequências, sistema de billing. Cada uma delas.
2. Mapeie os fluxos de dados entre elas. De onde entra dado? Para onde vai? Quais integrações transferem dados pessoais? Alguma envolve transferência internacional?
3. Identifique todas as fontes de enriquecimento de dados. Seus leads sabem que você tem informações sobre eles vindas de terceiros?

Semana 2: Auditoria

1. Documente cada automação com lógica condicional. Workflows de scoring, routing, sequências personalizadas, health scores. Para cada um: qual o propósito? Que dados usa? Que decisão automatizada faz?
2. Verifique base legal. Para cada tipo de dado e cada uso, qual a base legal sob a LGPD? Consentimento? Legítimo interesse? Execução de contrato?
3. Revise contratos com fornecedores de dados. Seus provedores de enriquecimento de dados têm cláusulas adequadas de proteção de dados? Eles garantem que os dados foram coletados legalmente?

Semana 3: Implementação

1. Ative mecanismos de opt-out. Em cada camada de automação, o lead/cliente deve ter uma saída clara. Se está usando a HubSpot, as configurações de portal do cliente e gerenciamento de consentimento são bons pontos de partida.
2. Crie um registro de automações. Pode ser uma planilha, um Notion, ou uma propriedade customizada no CRM. O formato importa menos que a disciplina de manter atualizado.
3. Defina uma cadência de revisão. Trimestral é o mínimo. Coloque no calendário. Com responsável definido.

Semana 4: Comunicação

1. Alinhe com jurídico/compliance. Se sua empresa tem uma área jurídica, traga-os para a conversa. Se não tem, considere uma consultoria pontual. O custo de uma consultoria preventiva é uma fração do custo de uma crise.
2. Comunique ao time. Marketing, Vendas e CS precisam entender por que certas práticas estão sendo revisadas. Sem contexto, a equipe vai sabotar involuntariamente as mudanças.
3. Documente a postura. Tenha um documento interno que declare: "esta é nossa política de governança de dados em operações de receita". Isso demonstra boa-fé perante reguladores e clientes.

Conclusão: a regulação vai chegar — a pergunta é se você estará pronto

A South Summit Brazil 2026 escancarou algo que muitos profissionais de tecnologia já sentiam intuitivamente: estamos operando numa velocidade que a sociedade ainda não regulou. Isso não é um bug — é uma característica estrutural de momentos de transição tecnológica. Aconteceu com a internet nos anos 90, com as redes sociais nos anos 2010, e está acontecendo agora com IA e automação de dados.

Mas para quem trabalha com RevOps, essa observação não pode ser apenas acadêmica. A distância entre "a regulação vai chegar" e "a regulação chegou e minha operação não está preparada" é menor do que parece. E o custo de adaptação tardia é brutalmente maior do que o custo de preparação antecipada.

Pense no que RevOps fundamentalmente é: a orquestração de pessoas, processos e tecnologia em torno da receita. Se os processos não incluem governança, se a tecnologia não inclui auditabilidade, se as pessoas não estão conscientes dos riscos — a orquestração está incompleta. E uma orquestra incompleta não produz harmonia; produz ruído.

O Framework GUARD não é uma solução definitiva. É um ponto de partida. Uma estrutura para tomar decisões responsáveis num ambiente de incerteza regulatória. Ele vai precisar ser adaptado conforme a regulação evoluir — e vai evoluir. Mas ter um framework imperfeito é infinitamente melhor do que não ter nenhum.

A provocação final é esta: se RevOps é a disciplina que alinha toda a máquina de receita, então governança de dados é RevOps. Não é tarefa do jurídico. Não é tarefa de TI. É tarefa de quem desenha os processos, configura as automações, implementa os scorings e conecta as ferramentas. É tarefa sua.

A South Summit mostrou que o ecossistema de inovação está empolgado com as possibilidades. E com razão — as possibilidades são reais. Mas empolgação sem estrutura é imprudência. E imprudência, em operações de receita, tem um custo que aparece em cada deal perdido, cada multa recebida e cada cliente que deixou de confiar em você.

A regulação vai chegar. A pergunta não é se. É quando. E quando ela chegar, você quer ser a empresa que precisa parar tudo — ou a que apenas ajusta um parafuso e segue operando?