DeepSeek V4 Lite: o que dá pra testar do modelo trilionário que ainda não saiu

DeepSeek V4 Lite: o que dá pra testar do modelo trilionário que ainda não saiu

O DeepSeek V4 completo ainda não saiu. Cada janela de março passou sem release. Mas desde 9 de março, uma coisa apareceu silenciosamente no site da DeepSeek: o V4 Lite. E dá para testar agora. O que sabemos do V4 completo é absurdo no papel: 1 trilhão de parâmetros totais, ~37 bilhões ativos por token via MoE, multimodal nativo, e uma arquitetura de memória chamada Engram que promete contexto longo real — não o "suporta 1M tokens mas esquece tudo depois de 200K" que a gente já viu. O Lite é o canário na mina. E os primeiros números são interessantes. MoE com 37B ativos de 1T total — por que isso importa Vamos parar nos números de arquitetura porque eles definem tudo: custo, latência, hardware necessário. Um modelo MoE de 1T parâmetros com 37B ativos por token significa que 96.3% dos pesos ficam inativos em cada forward pass. O router seleciona os experts relevantes, ativa ~37B de parâmetros, e o resto dorme. Na prática, o inference cost se aproxima ao de um modelo denso de 37B — mas com a capacidade representacional de 1T. Comparação direta:Modelo Params totais Params ativos/token Ratio ativoDeepSeek V4 1T ~37B 3.7%DeepSeek V3 685B ~37B 5.4%Mixtral 8x22B 176B ~44B 25%Qwen 3.5 72B 72B 72B (denso) 100%Llama 4 Maverick 400B ~17B 4.3%Notem que o V4 mantém os mesmos ~37B ativos do V3, mas com quase 50% mais parâmetros totais. Mais experts, mais especialização, mesmo custo de inference. É a tese central do MoE levada ao extremo: escalar capacidade sem escalar compute por token. O que isso significa na prática? Se o V4 Lite usa uma fatia desse MoE (provavelmente um subset de experts), o custo de rodar inference pode ser competitivo com modelos densos de 7-13B. E isso muda a conversa de deploy inteiro. Engram memory architecture: 97% NIAH em 1M tokens A feature mais interessante da arquitetura V4 é o que a DeepSeek chama de Engram memory — e que aparece parcialmente no V4 Lite. Needle-in-a-Haystack (NIAH) é o teste padrão para contexto longo: esconde um fato específico em diferentes posições de um contexto gigante e pede para o modelo recuperar. A maioria dos modelos começa a degradar seriamente acima de 200K tokens. O V4 reporta 97% de acurácia em NIAH com 1M tokens. Como? A Engram architecture adiciona uma camada de memória estruturada entre os blocos de atenção. Em vez de depender puramente de atenção sobre a sequência inteira (que escala quadraticamente), o modelo mantém "engramas" — representações comprimidas de segmentos anteriores que funcionam como uma cache semântica. A atenção local opera nos tokens recentes, e queries sobre contexto distante consultam os engramas. Não é uma ideia totalmente nova — lembra o Memorizing Transformers do Google em 2022 — mas a implementação parece substancialmente melhor. O V3 já tinha uma versão simplificada disso. O V4 parece ter transformado de feature experimental em peça central da arquitetura. O impacto prático é para qualquer aplicação de contexto longo: análise de codebases inteiras, processamento de documentos jurídicos, conversas longas com memória real. Se os 97% se confirmarem em testes independentes, é state-of-the-art. Otimizado para Huawei Ascend e Cambricon Aqui está o detalhe geopolítico que interessa para quem faz infra: o V4 foi explicitamente otimizado para rodar em Huawei Ascend 910B e Cambricon MLU370. Chips chineses. Isso não é capricho patriótico — é necessidade. Com as restrições de exportação americanas, a DeepSeek não pode contar com suprimento garantido de H100/H200 da NVIDIA. Então fizeram o que qualquer engenharia competente faria: otimizaram para o hardware disponível. Na prática, os kernels do V4 foram escritos com backends duplos: CUDA para quem tem NVIDIA, e kernels nativos para Ascend CANN e Cambricon MLUOps. O V3 já tinha suporte parcial a Ascend, mas com performance degradada de 30-40% vs CUDA. O V4 promete paridade. Para a comunidade global, o impacto é indireto mas real: se o modelo roda bem em hardware chinês de menor custo, cloud providers chineses podem oferecer inference mais barata. E quem acessa via API se beneficia. V4 Lite: o que dá pra testar agora O V4 Lite está acessível de duas formas: 1. Via chat no site da DeepSeek: Acesse chat.deepseek.com. Se o V4 Lite estiver disponível na sua região, aparece como opção de modelo no seletor. Não aparece para todos — rola um rollout gradual. 2. Via API: curl https://api.deepseek.com/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $DEEPSEEK_API_KEY" \ -d '{ "model": "deepseek-v4-lite", "messages": [{"role": "user", "content": "Explain MoE routing in transformers"}], "max_tokens": 2048 }'O pricing do V4 Lite está em ~US$0.07/1M input tokens e ~US$0.28/1M output tokens. Se confirmado, é mais barato que o V3 (US$0.27 input / US$1.10 output) e brutalmente mais barato que GPT-4o. Primeiros benchmarks: V4 Lite vs V3 vs Qwen 3.5 Esses números são dos primeiros testes públicos — da própria DeepSeek e de benchmarks independentes que apareceram no Hugging Face Open LLM Leaderboard nos últimos dias. Trate como preliminar.Benchmark V4 Lite DeepSeek V3 Qwen 3.5 72BMMLU 84.2 87.1 85.3HumanEval 82.9 85.4 80.1MATH 76.8 81.2 78.5GSM8K 91.3 94.6 92.1Arena-Hard 72.1 78.9 74.6O V4 Lite não bate o V3 completo — e não deveria. É uma versão reduzida, provavelmente com menos experts ativos e contexto menor. Mas compete direto com o Qwen 3.5 72B em coding (HumanEval 82.9 vs 80.1) enquanto custa uma fração para rodar. O ponto não é que o V4 Lite é o melhor modelo do mundo. O ponto é o ratio performance/custo. Se os números de pricing se confirmarem, estamos olhando para performance tier-Qwen-72B a custo tier-Llama-8B. Isso é MoE funcionando como deveria. O que falta: V4 completo e os pesos O elefante na sala é óbvio: cadê os pesos? O V3 foi open-weight desde o launch. A expectativa da comunidade é que o V4 siga o mesmo caminho. Mas o V4 completo simplesmente não apareceu. O paper do V3 saiu em dezembro de 2024 e os pesos vieram junto. Estamos em março de 2026 e só temos o Lite via API. Sem pesos, sem fine-tuning. Sem fine-tuning, o modelo é uma API — e APIs a gente já tem de sobra. O valor real do DeepSeek para a comunidade open-source sempre foi poder baixar, modificar e rodar local. Se o V4 demorar para abrir pesos, a janela de relevância fecha rápido — o Qwen 3.5 está aí, o Llama 4 está aí, e ambos já têm pesos. Veredito O DeepSeek V4 Lite é um preview convincente de uma arquitetura ambiciosa. A combinação de MoE agressivo (37B de 1T), Engram memory para contexto longo real, e otimização para hardware chinês mostra uma equipe de engenharia que está resolvendo problemas concretos, não perseguindo benchmark. Mas um preview é um preview. Sem pesos abertos, sem paper detalhado da Engram architecture, e sem o V4 completo, estamos avaliando promessas. Promessas muito bem fundamentadas nos resultados do V3 — mas promessas. O que vale agora: acessar a API, testar no seu use case, comparar com V3 e Qwen 3.5 nos seus dados. Os benchmarks públicos dizem uma coisa; seus dados dizem outra. API: platform.deepseek.com. Repo do V3 (para referência de arquitetura): github.com/deepseek-ai/DeepSeek-V3. Vai lá, testa, mede. E quando os pesos do V4 saírem, a gente conversa de novo.

Rox atinge US$1.2B de valuation — agentes autônomos de vendas são o novo SaaS?

Rox atinge US$1.2B de valuation — agentes autônomos de vendas são o novo SaaS?

A Rox AI acaba de ser avaliada em US$1.2 bilhão. A rodada, reportada pelo TechCrunch em 12 de março, coloca mais uma startup de agentes autônomos no clube dos unicórnios. Mas o que diferencia a Rox não é o valuation — é a tese. A empresa não construiu uma ferramenta que ajuda vendedores a vender melhor. Construiu agentes que substituem vendedores. Especificamente, SDRs: os profissionais de sales development que qualificam leads, fazem cold outreach e agendam reuniões. É uma distinção que parece sutil, mas muda tudo. E com US$20.8 bilhões acumulados em funding no setor de AI agents e 1.040 empresas ativas segundo o Tracxn, entender qual modelo de negócio vence não é exercício teórico — é questão de sobrevivência para quem constrói no espaço. Ferramenta vs. substituto: dois modelos, duas apostas O mercado de vendas B2B assistidas por IA tem dois paradigmas competindo pelo mesmo orçamento. O primeiro é o modelo ferramenta. Startups como Gong, Outreach e Apollo.io construíram plataformas que tornam vendedores mais produtivos. Gravam calls, sugerem follow-ups, automatizam sequências de email. O vendedor continua no centro. A IA é o co-piloto. O modelo de negócio é SaaS clássico: cobra por seat, escala com headcount do cliente. O segundo é o modelo substituto. É onde a Rox se posiciona. O agente não assiste o SDR — ele é o SDR. Pesquisa o lead, personaliza a abordagem, envia a mensagem, interpreta a resposta, qualifica e agenda a reunião. O humano entra quando o lead qualificado chega à reunião. O modelo de negócio é diferente: não cobra por seat (porque não tem seat), cobra por resultado — por reunião agendada, por lead qualificado, por pipeline gerado. A diferença econômica é brutal. Um SDR nos Estados Unidos custa entre US$60 mil e US$90 mil por ano em salário, mais benefícios, ramp-up de 3 meses e turnover médio de 18 meses. Um agente da Rox custa uma fração disso por lead qualificado, não precisa de onboarding e melhora com o tempo em vez de pedir demissão. Por que os investidores estão comprando a tese O valuation de US$1.2 bilhão num mercado onde Sierra já está em US$10 bilhões e Harvey em US$11 bilhões segue uma lógica consistente: agentes que substituem trabalho repetitivo e mensurável atraem capital porque o ROI é imediato e calculável. O cliente não precisa acreditar em transformação digital. Precisa comparar duas planilhas: quanto gasta com um time de 10 SDRs versus quanto gasta com agentes fazendo o mesmo trabalho. Se o output é equivalente e o custo é 70% menor, a decisão se toma sozinha. É o mesmo padrão que vimos na Sierra com atendimento ao cliente — a empresa que acabou de bater US$150 milhões de ARR cobrando por interação resolvida, não por seat. O modelo de precificação por resultado está se tornando o padrão para startups de agentes autônomos. O risco que ninguém está precificando Mas existe um risco estrutural que o mercado parece estar ignorando: dependência de modelo base. Agentes de vendas como os da Rox dependem de LLMs para interpretar contexto, gerar mensagens personalizadas e tomar decisões de qualificação. Quando a OpenAI muda preço de API, quando um modelo tem regressão de qualidade depois de um update, quando um provider sai do ar por duas horas — o agente para. E com ele, o pipeline de vendas do cliente. Para ferramentas SaaS tradicionais, um downtime de API de LLM é um inconveniente. Para um agente que substitui um time inteiro de SDRs, é uma parada de produção. Isso cria uma fragilidade que valuations de US$1.2 bilhão ainda não refletem. E o ecossistema brasileiro? O Brasil tem dois players relevantes no espaço de sales tech. A RD Station — hoje parte da TOTVS — domina inbound marketing e automação para PMEs. A Meetime construiu uma plataforma de inside sales com inteligência conversacional. Ambas operam no modelo ferramenta. A chegada de agentes autônomos como os da Rox apresenta um cenário dual. De um lado, é ameaça. Se o custo de um SDR nos EUA justifica substituição por agente, no Brasil a equação é diferente — SDRs custam menos, mas a produtividade média também é menor. A janela até que agentes de vendas em português tenham qualidade suficiente para competir com SDRs brasileiros não é infinita. De outro lado, é oportunidade. O mercado brasileiro de vendas B2B tem especificidades — ciclos de venda mais longos, relações mais pessoais, decisores que preferem WhatsApp a email — que um agente treinado em dados americanos não captura. Quem construir agentes de vendas nativamente brasileiros, que entendem o ritmo e os canais do mercado local, tem um moat defensável que a Rox não consegue replicar de Mountain View. O que falta é capital. Das 975 startups de IA ativas no Brasil, nenhuma está construindo agentes autônomos de vendas com a ambição (e o funding) da Rox. O BNDES e seu fundo bilionário para IA poderiam mudar isso, mas o ecossistema precisa de founders que pensem em substituição, não apenas em assistência. O que isso sinaliza A Rox não é uma anomalia — é um ponto de dados numa tendência clara. O mercado de agentes autônomos está migrando de "IA que ajuda profissionais" para "IA que faz o trabalho do profissional". Atendimento ao cliente já foi (Sierra). Jurídico está indo (Harvey). Vendas B2B é o próximo. Para quem constrói no espaço, a questão estratégica é simples: você está construindo o último upgrade para o vendedor humano ou o primeiro substituto? Ambos podem funcionar. Mas os valuations — e o capital — estão indo cada vez mais para quem responde a segunda opção.

SEC coloca IA como prioridade de exame em 2026 — compliance não é mais opcional

SEC coloca IA como prioridade de exame em 2026 — compliance não é mais opcional

A SEC (Securities and Exchange Commission) incluiu inteligência artificial e cybersecurity como prioridades centrais do seu programa de exames para 2026. O destaque não é a inclusão em si — é o que saiu da lista para dar lugar: crypto. Quando o regulador de valores mobiliários mais influente do mundo troca uma prioridade por outra, isso sinaliza onde o enforcement vai concentrar recursos. Para empresas com operação nos EUA, listadas ou que captam investimento americano, a implicação é direta: o uso de IA deixou de ser tema de inovação e virou tema de compliance. E compliance regulatório americano tem consequências financeiras concretas. O que a SEC está examinando O foco do programa de exames da SEC para IA se concentra em três áreas: Uso de IA em decisões de investimento. A SEC quer entender como gestoras de ativos, broker-dealers e advisors usam modelos de IA para recomendar investimentos, precificar ativos e gerenciar risco. A preocupação central é conflito de interesse — se a IA prioriza o retorno do cliente ou da instituição. IA em compliance e supervisão. Instituições que usam IA para monitorar compliance interno — detecção de fraudes, monitoramento de comunicações, análise de transações suspeitas — serão examinadas sobre a eficácia e a supervisão desses sistemas. Uma IA de compliance que não funciona adequadamente é pior que não ter IA: cria falsa sensação de segurança. Disclosures sobre IA. Empresas listadas que mencionam IA em seus filings, relatórios anuais e comunicações a investidores serão examinadas sobre a veracidade dessas declarações. Afirmar que usa IA para vantagem competitiva sem substância auditável é risco de disclosure inadequado. A SEC já sinalizou que "AI washing" — o equivalente ao greenwashing para IA — será tratado com seriedade. FTC: Operation AI Comply Em paralelo à SEC, a FTC (Federal Trade Commission) lançou a "Operation AI Comply", uma iniciativa de enforcement contra empresas que fazem marketing enganoso sobre capacidades de IA. As ações já resultaram em processos contra empresas que:Afirmaram que sua IA "detecta com 99% de precisão" sem evidência Prometeram resultados automatizados que dependiam de intervenção humana não divulgada Usaram o termo "IA" como diferencial de produto sem tecnologia real de machine learningA FTC está aplicando leis de proteção ao consumidor existentes a claims sobre IA. Não precisou de legislação nova. Usou o FTC Act para enquadrar publicidade enganosa que envolve IA. A lição é importante: a ausência de uma lei específica de IA não significa ausência de risco regulatório. Reguladores estão usando frameworks existentes para enforcement. Itália e o precedente europeu A autoridade de proteção de dados italiana (Garante) multou a OpenAI em 15 milhoes de euros por violações de GDPR relacionadas ao processamento de dados pessoais usados no treinamento do ChatGPT. A decisão cita falta de base legal adequada para processamento e falha em informar usuários sobre como seus dados foram utilizados. O caso é relevante por dois motivos. Primeiro, estabelece precedente de que dados de treinamento de IA estão sujeitos a regulação de privacidade — não apenas os dados processados em tempo de inferência. Segundo, demonstra que autoridades europeias estão dispostas a aplicar multas significativas contra empresas de IA. A multa de 15 milhoes de euros é modesta para a OpenAI, mas o precedente regulatório é substancial. Para empresas brasileiras que usam modelos de terceiros treinados com dados que podem incluir informações de cidadãos europeus, a cadeia de responsabilidade se estende. Não basta dizer "usamos a API da OpenAI" — é preciso entender e documentar a base legal para o tratamento de dados que o modelo processou durante o treinamento. Os quatro temas regulatórios universais Independentemente da jurisdição — SEC nos EUA, GDPR na Europa, LGPD no Brasil — quatro temas regulatórios aparecem em todas as frameworks de IA: 1. Transparência. Reguladores exigem que organizações sejam claras sobre quando e como usam IA. Isso inclui disclosure para clientes, investidores e reguladores. A opacidade algorítmica é o primeiro alvo de enforcement em qualquer jurisdição. 2. Prevenção de viés. Sistemas de IA que discriminam — por raça, genero, idade, localização — geram responsabilidade legal em praticamente todas as jurisdições. A SEC examina viés em decisões de investimento. A FTC examina viés em produtos de consumo. A LGPD protege contra decisões automatizadas discriminatórias. 3. Privacidade de dados. De onde vêm os dados que alimentam a IA? Como são processados? Quem consentiu? Essas perguntas estão no centro de GDPR, LGPD e das leis estaduais americanas de privacidade. A multa italiana contra a OpenAI demonstra que a resposta "são dados públicos" não é suficiente. 4. Accountability. Quando a IA erra, quem responde? Reguladores exigem que exista uma cadeia de responsabilidade clara. A SEC quer saber quem supervisiona a IA de investimento. A FTC quer saber quem validou os claims de marketing. A LGPD quer saber quem é o controlador da decisão automatizada. Esses quatro temas são o denominador comum. Uma empresa que endereça transparência, viés, privacidade e accountability de forma estruturada estará bem posicionada para compliance em qualquer jurisdição. Uma empresa que ignora qualquer um deles está exposta em todas. De guidelines para enforcement: o que mudou Até 2025, a maioria das orientações regulatórias sobre IA era principiológica. Documentos como o NIST AI RMF, os princípios de IA da OCDE e as diretrizes da UNESCO estabeleciam princípios gerais sem mecanismos de enforcement. Em 2026, o cenário é outro. A SEC examina. A FTC processa. A Garante italiana multa. O EU AI Act entra em enforcement em agosto. O PL 2338 avança no Brasil. Não são mais guidelines — são obrigações com consequências financeiras. A transição de guidelines para enforcement muda a equação de risco corporativo. O custo de ignorar IA governance não é mais reputacional — é financeiro, legal e operacional. E boards que não ajustaram sua postura de risco para refletir essa transição estão operando com informação desatualizada. Recomendações práticas 1. Crie um registro interno de use cases de IA. Documente todos os sistemas de IA em operação: fornecedor, dados utilizados, decisões influenciadas, população afetada, classificação de risco. Esse inventário é o pré-requisito para qualquer programa de compliance de IA. Sem ele, a organização não consegue responder à pergunta mais básica de qualquer regulador: "que IA vocês operam?" 2. Revise cláusulas contratuais com fornecedores de IA. Verifique se os contratos com provedores de modelos e APIs de IA incluem: indemnização por falhas do modelo, disclosure sobre dados de treinamento, compliance com regulações aplicáveis, direito de auditoria. A maioria dos contratos padrão de API não inclui essas cláusulas. Renegocie antes que o regulador pergunte. 3. Alinhe compliance de IA com compliance existente. Não crie um silo separado. IA governance deve se integrar aos programas de compliance, risco e auditoria interna existentes. A SEC não vai examinar IA isoladamente — vai examinar como a governança de IA se integra à governança corporativa geral. 4. Prepare um board briefing sobre exposição regulatória de IA. O conselho precisa entender a exposição atual da empresa em cada jurisdição onde opera. Inclua: regulações aplicáveis, status de compliance, gaps identificados, investimento necessário e timeline de adequação. 5. Monitore enforcement actions. As primeiras multas e processos definem precedentes que orientam a interpretação regulatória. A decisão italiana contra a OpenAI, as ações da FTC e os resultados dos exames da SEC em 2026 serão os precedentes que definirão o padrão de compliance para os próximos anos. O enforcement regulatório de IA começou. Não é futuro — é presente. A pergunta para o C-level não é mais "precisamos de governança de IA?" É "a governança que temos é suficiente para o regulador que está batendo na porta?"

PL 2338: o Marco Legal de IA do Brasil pode sair em 2026 — o que o board precisa saber

PL 2338: o Marco Legal de IA do Brasil pode sair em 2026 — o que o board precisa saber

O PL 2338/2023 — o projeto de lei que cria o Marco Legal de Inteligência Artificial no Brasil — foi aprovado pelo Senado em dezembro de 2024 e está em estágio final de análise na Câmara dos Deputados. Se aprovado em 2026, o Brasil terá um dos primeiros frameworks regulatórios de IA da América Latina, com modelo de classificação por risco inspirado no EU AI Act. Para quem lidera empresas que já operam IA em produção, o momento de atenção é agora. Não quando a lei for sancionada. O texto em discussão define obrigações concretas — e o custo de adequação retroativa é sempre maior que o de preparação antecipada. O que o PL 2338 estabelece O projeto adota o modelo de regulação baseada em risco que se tornou padrão global desde o EU AI Act. Na prática, isso significa que nem toda IA será regulada da mesma forma. O peso das obrigações depende do risco que o sistema representa para direitos fundamentais. Classificação por níveis de risco. Sistemas de IA serão classificados em categorias de risco — de mínimo a inaceitável. Sistemas de alto risco, como os usados em decisões de crédito, contratação, saúde e segurança pública, terão obrigações mais rigorosas de transparência, documentação e supervisão humana. Sistemas de risco inaceitável — como scoring social por parte do governo — serão proibidos. Direito de contestação de decisões algorítmicas. Qualquer pessoa afetada por uma decisão tomada ou substancialmente influenciada por IA terá direito de solicitar revisão humana. Isso impacta diretamente operações que automatizam decisões de crédito, seguros, processos seletivos e atendimento ao cliente. Empresas que operam IA em decisões sobre pessoas precisarão ter mecanismo de contestação documentado e funcional. Criação do SIA. O Sistema Nacional de Regulação e Governança de IA será o órgão central de coordenação. Uma autoridade competente — ainda em definição se será a ANPD, uma agência nova ou um modelo multisetorial — terá poder de fiscalização, aplicação de sanções e emissão de diretrizes. Sandboxes regulatórios. O projeto prevê ambientes controlados para que empresas testem inovações de IA sob supervisão regulatória, sem incorrer em penalidades durante o período de experimentação. Isso é positivo para startups e empresas em fase de desenvolvimento, mas não dispensa compliance para sistemas já em produção. O cenário regulatório global: três modelos em paralelo O C-level que opera em mais de um mercado precisa entender que não existe um padrão regulatório único. Existem três abordagens em movimento simultâneo — e nenhuma delas é opcional. EU AI Act — o mais avançado. Em vigor desde agosto de 2024, com requisitos de alto risco entrando em agosto de 2026. Multas de até 35 milhoes de euros ou 7% da receita global. Modelo prescritivo, com conformity assessments obrigatórios e registro em base de dados pública. Qualquer empresa que opera no mercado europeu precisa estar em compliance. Estados Unidos — patchwork estadual. Na ausência de uma lei federal, estados americanos avançam com legislação própria. Colorado, Illinois, Connecticut e Califórnia já têm ou avançam leis específicas sobre IA. A administração Trump emitiu uma ordem executiva com foco em preempção federal, mas sem força de lei vinculante. O resultado é um mosaico de obrigações que varia por estado. Empresas com operação nos EUA precisam monitorar legislação estadual ativamente. Brasil — PL 2338. Posicionado entre o modelo prescritivo europeu e a fragmentação americana, o projeto brasileiro busca equilíbrio entre regulação e inovação. A abordagem risco-baseada é moderna. A questão aberta é a execução: quem será a autoridade competente, com que orçamento, com que capacidade técnica e com que independência. Para empresas multinacionais brasileiras, o cenário exige compliance simultâneo em múltiplas jurisdições. Para empresas que operam apenas no Brasil, o PL 2338 será o piso regulatório — mas a LGPD já impõe obrigações que se sobrepõem. LGPD + PL 2338: a dupla regulatória A LGPD já trata de decisões automatizadas no artigo 20. Qualquer pessoa tem direito de solicitar revisão de decisões tomadas unicamente com base em tratamento automatizado de dados pessoais. Isso já se aplica a sistemas de IA que processam dados pessoais para tomar decisões. O PL 2338 amplia esse escopo. O direito de contestação não se limita a decisões baseadas em dados pessoais — abrange qualquer decisão substancialmente influenciada por IA, independentemente de envolver dados pessoais ou não. Uma IA que nega crédito com base em dados agregados e anonimizados, sem dados pessoais identificáveis, ainda estaria sujeita ao direito de contestação do PL 2338. A implicação para o board: a organização precisa mapear dois regimes regulatórios que se sobrepõem parcialmente. Compliance com LGPD não garante compliance com PL 2338, e vice-versa. Cada sistema de IA em produção precisa ser avaliado sob ambas as lentes. Riscos concretos para quem espera Três cenários que boards precisam considerar: Risco de adequação retroativa. Se o PL 2338 for aprovado com vacatio legis curta — e o texto atual prevê 12 a 24 meses — empresas terão uma janela limitada para classificar seus sistemas por risco, documentar processos, implementar mecanismos de contestação e ajustar governance. Quem começa antes tem vantagem operacional. Risco reputacional. A simples existência do debate regulatório já cria expectativa social. Consumidores, investidores e reguladores já esperam transparência no uso de IA. Uma empresa que não consegue explicar como sua IA toma decisões terá problema de reputação antes mesmo de ter problema legal. Risco de investimento. Fundos de investimento com critérios ESG e investidores institucionais estão incorporando governança de IA nas avaliações de due diligence. Empresas sem framework de governança de IA documentado perdem pontos em avaliações de risco — e isso afeta custo de capital. Recomendações para o C-level Para o General Counsel. Inicie o mapeamento de todos os sistemas de IA em produção que tomam ou influenciam decisões sobre pessoas. Classifique por risco usando os critérios do PL 2338 como referência. Cruze com obrigações existentes da LGPD. Identifique gaps. Para o CTO/CAIO. Implemente mecanismo de explicabilidade e contestação nos sistemas de alto risco antes que a lei exija. O custo de retrofit é significativamente maior que o de design. Sistemas desenvolvidos hoje sem explicabilidade precisarão ser refeitos. Para o CEO. Coloque o PL 2338 na pauta do próximo conselho. O board precisa entender três coisas: quais sistemas de IA a empresa opera, qual o nível de risco de cada um e qual é o gap entre o estado atual e o que a regulação vai exigir. Se as respostas não estiverem disponíveis, essa é a primeira providência. Para o CFO. Provisione orçamento para compliance de IA em 2026-2027. A experiência com LGPD mostrou que empresas que não alocaram recursos antecipadamente pagaram mais caro na corrida de adequação. O PL 2338 seguirá o mesmo padrão. O Marco Legal de IA do Brasil não é surpresa. Está em tramitação há três anos. A aprovação pode acontecer em 2026. Quem lidera empresas que usam IA em produção tem a obrigação fiduciária de estar preparado — não para a possibilidade de regulação, mas para a certeza dela.

Bank of America deploya agentes para 1.000 advisors — o case que boards vão citar

Bank of America deploya agentes para 1.000 advisors — o case que boards vão citar

O Bank of America deployou uma plataforma de advisory baseada em IA agêntica, construída sobre o Salesforce Agentforce, para aproximadamente 1.000 financial advisors. Não é piloto. Não é prova de conceito. É produção — com clientes reais, decisões reais e impacto mensurável no P&L de uma das maiores instituições financeiras do mundo. Esse é o case que vai mudar a conversa em boardrooms de todos os setores nos próximos trimestres. O contexto executivo: por que esse deploy é diferente O mercado de IA corporativa não tem escassez de anúncios. Tem escassez de deploys em produção com escala relevante. A maioria das organizações opera no ciclo piloto-piloto-piloto — testa em ambiente controlado, apresenta resultados promissores ao board, não consegue escalar, repete. O BofA quebrou esse ciclo. E o fez de uma forma que é difícil de ignorar por três razões: Primeiro: escala. Mil advisors não é um grupo de teste. É uma operação. Financial advisors do BofA gerenciam patrimônios significativos, tomam decisões que afetam diretamente a receita do banco e operam sob supervisão regulatória rigorosa. Deployar agentes de IA nesse contexto exigiu validação jurídica, de compliance, de segurança e de negócio. O fato de que passou por todos esses gates é o dado mais relevante para outros boards. Segundo: contexto regulado. O setor financeiro americano opera sob supervisão da SEC, FINRA, OCC e uma constelação de reguladores estaduais. Cada interação com cliente pode ser auditada. Cada recomendação de investimento tem requisitos de suitability. Deployar IA agêntica nesse ambiente não é instalar um chatbot — é integrar um sistema autônomo numa cadeia de compliance que existe há décadas. Se o BofA conseguiu, a barra de "nosso setor é muito regulado para IA" ficou significativamente mais alta. Terceiro: não é o primeiro movimento. O BofA já opera a Erica, assistente virtual que atende milhões de clientes e executa trabalho equivalente a aproximadamente 11.000 funcionários. Esse número merece atenção do CFO de qualquer organização: 11.000 FTEs equivalentes. Não é projeção — é operação corrente. O deploy para advisors é a extensão dessa capacidade para o segmento de alto valor, onde o impacto por advisor é substancialmente maior. O cenário: IA agêntica sai do piloto O BofA não está sozinho, mas está na frente. O setor financeiro e adjacências concentram os deploys mais maduros de IA agêntica em produção:Harvey AI opera no setor jurídico com avaliação de US$ 11 bilhões e mais de 100.000 advogados usando a plataforma. Agentes que revisam contratos, pesquisam jurisprudência e preparam documentos legais. Sierra atingiu US$ 150 milhões em receita anual recorrente com agentes de atendimento ao cliente que resolvem problemas, não apenas respondem perguntas. Salesforce Agentforce — a plataforma sobre a qual o BofA construiu — se posiciona como a infraestrutura padrão para IA agêntica enterprise.O padrão que emerge é claro: IA agêntica em produção está se concentrando em setores com processos estruturados, compliance nativa e tolerância zero para improvisação. Não é coincidência. Por que serviços financeiros está na frente O Gartner projeta que 40% dos projetos de IA agêntica serão cancelados até 2027 por falha de governança. Essa estatística assusta — e deveria. Mas o setor financeiro tem três vantagens estruturais que reduzem significativamente esse risco: Processos documentados. Bancos não operam com processos informais. Cada fluxo de trabalho — abertura de conta, análise de crédito, recomendação de investimento, compliance KYC — está documentado, mapeado e auditável. Agentes de IA precisam exatamente disso para operar com consistência: processos claros com inputs, outputs e regras de negócio definidos. O que para outros setores é um pré-requisito difícil de construir, para serviços financeiros já existe. Audit trails nativos. Regulação financeira exige registro de decisões há décadas. Essa infraestrutura de logging e auditoria é a mesma que IA agêntica precisa para observabilidade. Quando um agente toma uma decisão, o sistema precisa registrar o quê, por quê e com quais dados. Bancos já fazem isso para decisões humanas. Estender para decisões algorítmicas é incremental, não transformacional. Cultura de compliance. Em setores menos regulados, governança de IA é percebida como burocracia que desacelera inovação. Em serviços financeiros, compliance é condição de operação. Equipes de risco, jurídico e compliance já participam do ciclo de desenvolvimento de produtos. Incluir IA agêntica nesse ciclo é uma extensão natural — não uma revolução cultural. A recomendação aqui é direta: se a organização opera em setor menos regulado e quer escalar IA agêntica, copie a abordagem do setor financeiro. Não a tecnologia — a governança. Documente processos antes de automatizá-los. Construa audit trails antes de deployar agentes. Integre compliance no ciclo de desenvolvimento, não depois. A métrica que o CFO vai usar "Equivalente a 11.000 funcionários." Essa é a métrica que a Erica do BofA produz e que vai aparecer em toda apresentação de business case de IA nos próximos meses. É uma métrica poderosa e perigosa ao mesmo tempo. Poderosa porque traduz capacidade de IA em linguagem de P&L — o CFO entende FTEs, entende custo de headcount, entende o impacto de alocar 11.000 pessoas para outras atividades. Perigosa porque simplifica uma realidade complexa: a Erica não substitui 11.000 funcionários — ela executa volume de trabalho equivalente em tarefas específicas. A distinção importa para dimensionar expectativas corretamente. Para boards avaliando investimento em IA agêntica, o framework de análise deveria incluir:Volume de tarefas automatizáveis: Quantas horas de trabalho estruturado existem na organização que podem ser executadas por agentes? Não todas as horas — apenas as que envolvem processos documentados, regras claras e dados acessíveis. Custo de erro: Qual o impacto financeiro e reputacional quando um agente erra? Em financial advisory, um erro pode gerar processo regulatório. Em atendimento ao cliente, pode gerar churn. O custo de erro define o nível de supervisão humana necessário — e esse custo precisa estar no business case. Tempo para valor: O BofA não chegou aqui em seis meses. A Erica foi lançada em 2018. São oito anos de construção iterativa de capacidade de IA. Boards que esperam ROI de IA agêntica em dois trimestres estão dimensionando errado o investimento necessário.Os riscos que o board precisa discutir Risco de dependência de plataforma. O BofA construiu sobre Salesforce Agentforce. Essa escolha cria dependência de um fornecedor específico para uma capacidade que será cada vez mais crítica. O board deve avaliar: existe estratégia de saída? Existe portabilidade? O lock-in é aceitável dado o valor entregue? Essas perguntas não são técnicas — são estratégicas. Risco de governança em escala. Mil advisors é relevante. Mas quando o deploy chegar a 10.000 — e chegará — a complexidade de governança cresce de forma não linear. Mais agentes, mais interações, mais edge cases, mais decisões autônomas que precisam ser monitoradas. A infraestrutura de observabilidade que funciona para 1.000 pode não escalar para 10.000 sem investimento adicional significativo. Risco de expectativa desalinhada. O case do BofA vai gerar pressão em boards de todos os setores: "se o Bank of America fez, por que nós não fizemos?" Essa pressão pode levar a deploys apressados, sem a governança adequada, sem os processos documentados, sem a cultura de compliance. E é exatamente isso que alimenta a projeção do Gartner de 40% de fracasso. O case do BofA deve inspirar — não apressar. Recomendações para a liderança Para o CEO: Use o case do BofA como referência, não como blueprint. A vantagem do setor financeiro é estrutural — processos regulados, audit trails, cultura de compliance. Se a organização não tem esses fundamentos, o primeiro investimento é construí-los. Deployar agentes antes de ter governança é acumular o risco que o Gartner quantificou. Para o CFO: A métrica de 11.000 FTEs equivalentes é o benchmark. Mas exija do time de IA um business case que inclua custo de governança, custo de erro e timeline realista. O ROI de IA agêntica é real — mas não é instantâneo. O BofA investiu oito anos para chegar aqui. Para o CAIO: Avalie a maturidade de processos antes da maturidade de tecnologia. Agentes de IA escalam onde processos são claros. Mapeie os 20% de processos da organização que concentram 80% do volume de trabalho estruturado — esse é o ponto de partida para IA agêntica em produção. Para o General Counsel: O deploy do BofA em ambiente regulado SEC/FINRA demonstra que compliance e IA agêntica são compatíveis. Mas exige integração de compliance no ciclo de desenvolvimento desde o dia zero. Revise os contratos com fornecedores de plataforma de IA para garantir cláusulas de auditoria, portabilidade de dados e responsabilidade por decisões algorítmicas. O que fica O Bank of America fez o que a maioria das organizações ainda discute em slides: colocou IA agêntica em produção, em escala, em ambiente regulado. Isso muda o patamar da conversa. O argumento de que "IA agêntica não está pronta para produção" perdeu sustentação factual. O argumento de que "nosso setor é muito regulado" também. O que resta é a execução. E execução em IA agêntica exige o que sempre exigiu em qualquer transformação operacional: processos claros, governança robusta, investimento paciente e liderança que entende que escala sem controle é risco, não velocidade. O BofA mostrou o caminho. Os 40% do Gartner mostram o que acontece com quem tenta atalhos.

MCP cruza 97 milhões de installs: o protocolo da Anthropic que virou a infraestrutura invisível dos agentes

MCP cruza 97 milhões de installs: o protocolo da Anthropic que virou a infraestrutura invisível dos agentes

Em 25 de março de 2026, o Model Context Protocol atingiu 97 milhões de downloads mensais do SDK. No lançamento, em novembro de 2024, eram 2 milhões. Isso é um crescimento de 4.750% em dezesseis meses — a curva de adoção mais rápida de qualquer padrão de infraestrutura de IA na história. Se você está construindo agentes e ainda não integrou MCP, este artigo é um alerta. De protocolo obscuro a infraestrutura de facto Quando a Anthropic lançou o MCP no final de 2024, a reação do mercado foi morna. Mais um protocolo? Mais um padrão aberto que uma empresa cria para servir seus próprios interesses? A desconfiança era compreensível — o histórico de "padrões abertos" controlados por big techs não é exatamente inspirador. O ponto de inflexão veio quando a OpenAI anunciou, em 2025, que adotaria o MCP como padrão de integração para seus agentes. Quando o criador do GPT decide usar o protocolo do concorrente em vez de construir o próprio, o mercado percebe que algo diferente está acontecendo. Google seguiu com o Gemini. Frameworks de agentes como LangChain, CrewAI e AutoGen integraram MCP em suas stacks. Em menos de um ano, a pergunta deixou de ser "vamos suportar MCP?" e virou "qual servidor MCP a gente conecta primeiro?" Hoje são mais de 5.800 servidores MCP — entre comunitários e enterprise — cobrindo bancos de dados, CRMs, provedores de nuvem, ferramentas de produtividade, plataformas de desenvolvimento, e-commerce e analytics. Todo grande provedor de IA suporta o protocolo. Claude, GPT-5.4, Gemini, todos falam MCP. O que o MCP resolve (e por que isso importa mais do que parece) A explicação mais simples: MCP é para agentes de IA o que USB-C é para dispositivos. Um conector universal que padroniza como agentes se conectam a ferramentas e fontes de dados externas. Antes do MCP, cada integração era custom. Quer que seu agente acesse o Salesforce? Escreva um conector. PostgreSQL? Outro conector. Google Calendar? Mais um. Cada combinação de modelo + ferramenta exigia implementação específica. Para uma startup construindo um agente que precisa acessar dez ferramentas, isso significava dez integrações distintas, cada uma com sua autenticação, formato de dados e tratamento de erros. O MCP padroniza tudo isso. Um servidor MCP para o Salesforce funciona com qualquer cliente MCP — seja ele rodando Claude, GPT ou um modelo open-source. O agente não precisa saber como cada ferramenta funciona internamente. Ele fala MCP, o servidor traduz. Um paper recente no arxiv (2603.13417) — "Bridging Protocol and Production: Design Patterns for Deploying AI Agents with MCP" — documenta os padrões de design que estão emergindo. Não é mais teoria. Empresas estão deployando agentes em produção usando MCP como camada de integração padrão. As dores de crescimento de um protocolo que cresceu rápido demais Crescer 4.750% em dezesseis meses tem consequências. O roadmap de 2026 do MCP, detalhado pela The New Stack, aborda problemas reais que surgiram com a adoção em escala. Autenticação e autorização. Quando o MCP era usado por desenvolvedores em ambientes locais, auth era um detalhe. Com servidores enterprise conectando agentes a sistemas críticos — ERP, bancos de dados financeiros, plataformas de compliance — a camada de segurança precisa ser robusta. O roadmap promete um framework de autenticação padronizado, mas por enquanto cada implementação resolve isso de forma diferente. Streaming e estado. Agentes em produção precisam manter contexto entre chamadas e lidar com operações de longa duração. O protocolo original foi desenhado para interações request-response simples. Adaptar isso para fluxos complexos — onde um agente monitora um pipeline de dados em tempo real, por exemplo — exige extensões que ainda estão sendo definidas. Governança de servidores. Com 5.800+ servidores, a qualidade varia enormemente. Alguns são mantidos por enterprises com SLA. Outros são projetos de fim de semana de um desenvolvedor que pode abandonar o repo amanhã. Para empresas que dependem de um servidor MCP em produção, a questão de quem mantém e garante a estabilidade é real. São dores legítimas. Mas são dores de crescimento, não de design. O protocolo funciona. O desafio agora é fazê-lo funcionar em escala enterprise com as garantias que produção exige. O elefante na sala: Anthropic controla o protocolo Não dá para analisar o MCP sem discutir quem o controla. A Anthropic criou o protocolo, mantém o repositório principal e define o roadmap. Sim, é open-source. Sim, qualquer um pode contribuir. Mas a governança é da Anthropic. Isso é ao mesmo tempo uma força e um risco. Força porque garante coerência de design e velocidade de evolução — não há comitê de 47 empresas discutindo a cor do bikeshed. Risco porque a Anthropic é uma empresa com interesses comerciais. Se em algum momento o protocolo evoluir de uma forma que favorece o ecossistema Claude em detrimento de outros, a neutralidade desmorona. Até agora, a Anthropic jogou o jogo certo. Manter o protocolo aberto o suficiente para que a OpenAI adotasse foi um movimento estratégico brilhante. Quando seu maior concorrente usa sua infraestrutura, você não precisa vencer a guerra dos modelos para controlar o ecossistema. É a mesma lógica que fez o Android dominar mobile. Google não precisava que todo mundo usasse Pixel. Precisava que todo mundo usasse Android. A Anthropic não precisa que todo mundo use Claude. Precisa que todo mundo use MCP. O que isso significa para startups brasileiras Aqui é onde a análise fica prática. O ecossistema brasileiro de agentes de IA está crescendo rápido. BNDES lançou fundo de R$1 bilhão para IA, aceleradoras estão financiando startups de agentes verticais, empresas como Stone, Nubank e iFood estão construindo capacidade interna de agentes. Se essas startups e times internos estão construindo agentes sem MCP, estão criando silos. Cada integração custom é dívida técnica. Cada conector proprietário é uma barreira para interoperabilidade. Quando um cliente pergunta "seu agente se integra com nosso CRM?" e a resposta é "precisamos de 3 semanas para construir o conector", o concorrente que responde "sim, via MCP" vence. A recomendação é direta: se você está construindo agentes no Brasil, MCP não é opcional. É a camada de integração que o ecossistema global padronizou. Ignorar isso é o equivalente a construir um app mobile que não roda em Android. Tecnicamente possível. Comercialmente suicida. Para quem quer ir além de consumir o protocolo, há oportunidade em contribuir. O ecossistema de servidores MCP ainda tem gaps significativos para ferramentas e plataformas populares no Brasil — Totvs, RD Station, Pipefy, Conta Azul. Construir e manter servidores MCP para o stack brasileiro é uma forma de gerar valor e posicionar-se no ecossistema global. O ponto que importa 97 milhões de installs não é uma métrica de vaidade. É a prova de que o ecossistema de agentes convergiu para um padrão de integração. Não é perfeito — o roadmap de 2026 mostra que há problemas reais a resolver. Não é neutro — a Anthropic controla a direção. Mas é o padrão. E em infraestrutura, o padrão vence o melhor. A Anthropic fez algo que nenhum outro player de IA conseguiu: criou a camada de interoperabilidade que todos usam. Não vendendo modelos. Vendendo o protocolo que conecta modelos ao mundo. E quem controla a conexão, controla o ecossistema.

Trump monta conselho de IA com Zuckerberg, Huang e Ellison — Musk e Altman ficaram de fora

Trump monta conselho de IA com Zuckerberg, Huang e Ellison — Musk e Altman ficaram de fora

Quem senta à mesa decide o cardápio. Em 25 de março de 2026, Donald Trump nomeou 13 membros para o PCAST — President's Council of Advisors on Science and Technology — e a lista de nomes é tão reveladora pelo que inclui quanto pelo que exclui. Mark Zuckerberg. Jensen Huang. Larry Ellison. Marc Andreessen. Sergey Brin. Lisa Su. Mais sete nomes do topo do setor de tecnologia. Presidindo o conselho: David Sacks, o czar de IA e cripto do governo, e Michael Kratsios, diretor do OSTP (Office of Science and Technology Policy). Agora, os ausentes: Elon Musk e Sam Altman. Não é um detalhe menor. É a notícia. O que é o PCAST e por que importa O PCAST existe desde 1933, sob diferentes nomes. É um conselho consultivo que orienta o presidente sobre política de ciência e tecnologia. Em teoria, é consultivo. Na prática, suas recomendações moldam legislação, alocação de orçamento e prioridades de agências federais. Este PCAST tem um mandato específico: pesquisa em IA, desenvolvimento de chips, estratégia de força de trabalho e segurança nacional. E chega cinco dias depois do National AI Legislative Framework anunciado em 20 de março — o documento que vai virar a base da regulação de IA quando chegar ao Congresso. Conecte os pontos. O framework define os princípios. O PCAST define como esses princípios viram política. As pessoas nesse conselho vão literalmente escrever as regras do jogo. Quem está na mesa Vamos olhar para a composição. Zuckerberg lidera a Meta, dona do Llama e com investimentos massivos em IA aberta. Jensen Huang comanda a NVIDIA, que fornece o hardware que faz tudo funcionar. Larry Ellison está à frente da Oracle, cuja infraestrutura de cloud é cada vez mais central para treinamento de modelos. Lisa Su dirige a AMD, a principal alternativa à NVIDIA em GPUs. Sergey Brin voltou ao dia a dia do Google especificamente para IA. Marc Andreessen investe em metade das startups de IA do Vale do Silício. O padrão é claro: são executivos de empresas que vendem IA, vendem o hardware para IA ou investem em IA. Não há acadêmicos de IA safety. Não há representantes de organizações de direitos digitais. Não há cientistas sociais estudando impacto de IA no trabalho. O conselho pode crescer até 24 membros. Mas a composição inicial define o tom. E o tom é: Big Tech no comando. Quem ficou de fora — e por quê A exclusão de Elon Musk é, no mínimo, curiosa. Musk foi um dos maiores apoiadores de Trump na campanha de 2024. Liderou o DOGE (Department of Government Efficiency). Fundou a xAI, que recentemente se fundiu com a SpaceX. Tem mais acesso ao presidente que quase qualquer outro CEO de tecnologia. E mesmo assim, não está no PCAST. Há várias teorias. A mais pragmática: conflito de interesses. Musk tem contratos governamentais pela SpaceX, pela Tesla e agora pela xAI integrada. Colocá-lo num conselho que influencia regulação de IA enquanto ele compete diretamente nesse mercado seria difícil de justificar — mesmo para um governo que não se preocupa muito com aparências. A exclusão de Sam Altman tem outra lógica. A OpenAI está caminhando para um IPO. Altman está no processo de reestruturar a empresa de non-profit para for-profit. Reguladores da SEC estão de olho. Ter o CEO de uma empresa em transição regulatória sentado num conselho que define regulação de IA seria, digamos, inconveniente. Mas não se engane: ambos terão influência indireta. Musk pelo acesso pessoal a Trump. Altman pelo peso financeiro da OpenAI e seu lobby em Washington. A diferença é que influência informal não aparece em atas de reunião. O que esse conselho vai fazer de verdade O mandato oficial é amplo: pesquisa de IA, chips, workforce, segurança nacional. Mas o que importa é o que está entre as linhas. Chips: Os EUA estão em guerra de semicondutores com a China. O CHIPS Act alocou bilhões para fabricação doméstica. O PCAST vai recomendar onde investir mais, quais restrições de exportação manter e quais afrouxar. Com Jensen Huang e Lisa Su na mesa, espere recomendações que favoreçam expansão de capacidade e menos restrição à cadeia de suprimentos — o que é bom para NVIDIA e AMD. Regulação de IA: O framework de 20 de março é deliberadamente vago. Fala em "inovação responsável" e "liderança americana" sem definir limites concretos. O PCAST vai preencher essas lacunas. Com executivos de Big Tech escrevendo as sugestões, a direção provável é regulação leve — disclosure voluntário, sandboxes regulatórios, nada que atrapalhe o deployment rápido. Força de trabalho: Este é o tema que ninguém quer tocar com honestidade. IA está eliminando empregos. O conselho vai ter que recomendar algo sobre requalificação, mas sem um único representante trabalhista na mesa, espere soluções que priorizem eficiência corporativa sobre proteção ao trabalhador. Segurança nacional: IA militar é o elefante na sala. Os EUA estão acelerando integração de IA em defesa. O PCAST vai opinar sobre parcerias público-privadas nessa área. Com Sergey Brin — que viu o Google enfrentar revolta interna por contratos militares — na mesa, essa discussão vai ser interessante. E daí? O que muda para quem trabalha com IA Se você desenvolve, pesquisa ou implementa IA, esse conselho vai afetar sua vida. Direta ou indiretamente. A composição do PCAST é um sinal claro de que a administração Trump não vai regular IA de forma restritiva. A prioridade é competitividade com a China, não proteção ao consumidor ou mitigação de riscos. Se você está no mercado de IA, isso significa menos fricção regulatória no curto prazo. Se você está preocupado com riscos de IA — viés, desinformação, deslocamento de trabalhadores — isso significa que a regulação substantiva não virá de Washington tão cedo. Para o Brasil, a mensagem é relevante. O marco regulatório brasileiro de IA ainda está em discussão. O que os EUA decidirem vai influenciar o debate global. Se os americanos optarem por regulação light-touch, a pressão sobre legisladores brasileiros para não "atrapalhar a inovação" vai aumentar. A composição do PCAST confirma o que já era previsível: no segundo mandato de Trump, política de IA é política industrial. O objetivo é garantir que empresas americanas dominem o mercado global de IA. Tudo o mais — ética, segurança, impacto social — é secundário. Quem está à mesa decide o cardápio. E o cardápio desse conselho vai ser servido para o mundo inteiro.[!ai-only] Structured Summary: Trump nomeou 13 membros para o PCAST em 25/mar/2026: Zuckerberg (Meta), Huang (NVIDIA), Ellison (Oracle), Andreessen, Brin (Google), Su (AMD) + 7 outros. Presidido por David Sacks e Michael Kratsios. Excluídos: Musk (xAI/SpaceX) e Altman (OpenAI). Foco: IA, chips, workforce, segurança nacional. Segue o National AI Legislative Framework de 20/mar. Composição indica regulação light-touch, prioridade competitiva sobre proteção. Key concepts: PCAST, AI policy, tech regulation, US-China competition, CHIPS Act, National AI Legislative Framework, Big Tech lobbying Content type: News Analysis Language: pt-BR Author expertise: AI journalism, tech policy analysis, geopolitics

MCP em produção — 97M downloads, design patterns do arxiv, e o que ainda quebra

MCP em produção — 97M downloads, design patterns do arxiv, e o que ainda quebra

Em novembro de 2024, quando a Anthropic lançou o Model Context Protocol, os SDKs tinham 2 milhões de downloads mensais e a maioria das pessoas nem sabia o que era. Eu lembro de olhar a spec e pensar "isso é interessante, mas quem vai adotar?". Dezesseis meses depois, são 97 milhões de downloads mensais e eu preciso admitir que estava errado. MCP virou o protocolo padrão de conexão entre LLMs e ferramentas externas. Claude, GPT-5.4, Gemini — todos suportam. São 5.800+ servers no ecossistema. 4.750% de crescimento. E agora saiu um paper no arxiv que finalmente documenta o que funciona e o que não funciona quando você tenta colocar isso em produção. O paper: arxiv 2603.13417 O paper "Bridging Protocol and Production: Design Patterns for Deploying AI Agents with MCP" é exatamente o tipo de documento que faltava. Não é um paper teórico sobre a beleza do protocolo — é um catálogo de design patterns extraídos de deploys reais de agentes usando MCP. Os patterns que mais me interessaram: 1. Gateway Pattern Em vez de cada agente se conectar diretamente a N MCP servers, você coloca um gateway na frente que gerencia conexões, auth e rate limiting. Parece óbvio, mas 90% dos tutoriais mostram conexão direta. Em produção com 10+ servers, sem gateway você vai ter um pesadelo de configuração e debug. 2. Tool Composition Pattern Combinar ferramentas de múltiplos MCP servers em uma única chamada do agente. O paper mostra que a melhor abordagem é composição declarativa — o agente declara o que precisa, e o orquestrador resolve quais servers chamar. Tentativas de composição imperativa (o agente decidindo a sequência de chamadas) são frágeis e difíceis de debugar. 3. Fallback Chain Pattern Quando um MCP server não responde, ter uma cadeia de fallback com servers alternativos. O paper documenta três estratégias: retry simples, fallback para server alternativo, e degradação graceful (retornar resultado parcial). Na prática, já implementei a terceira e é a que menos frustra o usuário final. 4. Context Window Management O pattern mais técnico e mais útil. MCP servers podem retornar quantidades enormes de contexto — um server de database pode devolver milhares de linhas. O paper propõe um context budget por tool call, onde o orquestrador limita o output de cada server para caber no context window do modelo. Sem isso, um server guloso come o contexto inteiro e o agente perde acesso às outras ferramentas. Hands-on: criando um MCP server Chega de teoria. Vamos montar um MCP server básico que expõe uma API de busca para um agente. TypeScript (SDK oficial) npm install @modelcontextprotocol/sdkimport { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"; import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; import { z } from "zod";const server = new McpServer({ name: "search-server", version: "1.0.0", });// Registra uma tool que o agente pode chamar server.tool( "search_docs", "Busca na documentação interna", { query: z.string().describe("Termo de busca"), limit: z.number().default(5).describe("Máximo de resultados"), }, async ({ query, limit }) => { // Aqui vai sua lógica real — Elasticsearch, pgvector, whatever const results = await searchIndex(query, limit); return { content: [ { type: "text", text: JSON.stringify(results, null, 2), }, ], }; } );const transport = new StdioServerTransport(); await server.connect(transport);Python (SDK via PyPI) pip install mcpfrom mcp.server import Server from mcp.server.stdio import stdio_server from mcp.types import TextContent, Toolserver = Server("search-server")@server.tool() async def search_docs(query: str, limit: int = 5) -> list[TextContent]: """Busca na documentação interna.""" results = await search_index(query, limit) return [TextContent(type="text", text=str(results))]async def main(): async with stdio_server() as (read, write): await server.run(read, write, server.create_initialization_options())if __name__ == "__main__": import asyncio asyncio.run(main())Ambos os SDKs usam stdio como transport padrão — o client spawna o server como processo filho e se comunica via stdin/stdout. Isso é simples para desenvolvimento, mas em produção você vai querer HTTP/SSE (Server-Sent Events), que ambos os SDKs já suportam. Conectando no Claude Desktop (teste rápido) Edite o claude_desktop_config.json: { "mcpServers": { "search-docs": { "command": "node", "args": ["./dist/server.js"] } } }Reinicie o Claude Desktop e a tool search_docs aparece disponível. O agente pode invocá-la naturalmente durante a conversa. O que ainda quebra em produção Aqui é onde eu troco o chapéu de entusiasta pelo de engenheiro cansado. MCP em produção tem problemas reais que o hype esconde. Auth cross-server O maior gap. Cada MCP server gerencia sua própria autenticação. Se você tem 15 servers, o usuário precisa autenticar em cada um separadamente. Não existe um padrão de SSO ou token federation nativo no protocolo. O blog da WorkOS documenta bem esse problema e propõe soluções, mas nenhuma é oficial ainda. Na prática, o que eu faço é injetar tokens via variáveis de ambiente no momento do spawn do server. Funciona, mas é um hack — e não escala para cenários onde o token precisa ser refreshed durante a sessão. Session state MCP sessions são stateless por padrão. Se o server crashar e reiniciar, todo o contexto acumulado se perde. O paper do arxiv propõe um State Checkpoint Pattern, mas ninguém implementou isso nos SDKs oficiais ainda. Se seu agente depende de estado acumulado ao longo de uma conversa (e a maioria depende), você precisa implementar persistência por conta própria. Streaming O suporte a streaming de respostas longas é inconsistente entre implementações. O SDK TypeScript lida bem com SSE, mas o SDK Python tem edge cases com backpressure que podem causar memory leaks em sessões longas. Já perdi horas debugando isso. Observabilidade Não existe um padrão de tracing entre client e servers MCP. Se uma cadeia de 5 tool calls falha, boa sorte descobrindo onde foi. Eu adaptei OpenTelemetry manualmente nos meus servers, mas deveria ser built-in. Roadmap 2026: o que vem por aí O The New Stack publicou o roadmap que a comunidade está trabalhando. Os pontos mais relevantes:Auth padronizado: OAuth 2.1 como padrão de autenticação para MCP servers. Finalmente. Streamable HTTP transport: substituição do SSE por um transport mais robusto para produção. Registry protocol: um padrão para discovery de MCP servers — tipo um DNS para ferramentas de agentes. Elicitation: capacidade do server pedir informação adicional ao usuário via o client, sem interromper o fluxo do agente.Se o auth padronizado e o registry saírem no Q2 como prometido, MCP vira um protocolo enterprise-ready de verdade. Até lá, prepare-se para escrever bastante glue code. Veredito MCP não é mais experimental. 97 milhões de downloads mensais e suporte universal dos providers transformaram o protocolo em padrão de facto. O paper arxiv 2603.13417 é leitura obrigatória para quem está deployando agentes — os design patterns economizam semanas de tentativa e erro. Mas "padrão de facto" não significa "maduro". Auth, state e observabilidade são problemas reais que você vai enfrentar. O roadmap promete resolver boa parte disso em 2026, e a velocidade da comunidade (de 2M para 97M downloads em 16 meses) me dá alguma confiança. Se você ainda não tem MCP servers no seu stack de agentes, comece com o Gateway Pattern e um server simples como o exemplo acima. Mantenha o escopo pequeno, instrumente tudo, e prepare-se para reescrever o auth quando o padrão OAuth 2.1 sair. Paper: arxiv.org/abs/2603.13417. SDK TypeScript: @modelcontextprotocol/sdk. SDK Python: mcp no PyPI. Vai lá, monta um server, quebra em produção, e me conta o que deu errado.

OpenAI mata o Sora: US$ 1 milhão por dia e ninguém usando

OpenAI mata o Sora: US$ 1 milhão por dia e ninguém usando

A OpenAI matou o Sora. Não reduziu, não pausou, não "pivotou para enterprise". Matou. App iOS, API, sora.com — tudo vai ser desligado. O anúncio veio em 24 de março de 2026, sem muita cerimônia, quase escondido entre outras notícias da empresa. E esse silêncio diz tanto quanto o encerramento em si. Estamos falando do primeiro grande fracasso público da OpenAI. A empresa que está comprando tudo que se move — 17 aquisições e contando — não conseguiu fazer seu produto de vídeo mais hypado se pagar. A economia não fechou. Simples assim. Os números que enterraram o Sora Vamos aos fatos, porque aqui é onde a história fica feia. Entre novembro de 2025 e fevereiro de 2026, os downloads do app do Sora caíram 67%. O pico de aproximadamente 1 milhão de usuários derreteu para menos de 500 mil. Para uma empresa do tamanho da OpenAI, meio milhão de usuários não é tração — é ruído estatístico. Enquanto isso, o custo operacional girava em torno de US$ 1 milhão por dia. Por dia. Geração de vídeo consome GPU como nenhuma outra tarefa de IA generativa. Cada prompt transformado em vídeo é uma queimação de compute que faz o treinamento de LLMs parecer econômico em comparação. A conta não fecha de jeito nenhum. Mesmo que todos os 500 mil usuários fossem pagantes — e não eram — a receita não cobriria nem uma fração desse custo. O Sora era um buraco negro financeiro com um belo trailer de marketing. A Disney disse não — e isso doeu Talvez o sinal mais claro de que o Sora estava em apuros tenha vindo de fora da OpenAI. A Disney estava em negociações para um investimento de US$ 1 bilhão que incluiria integração profunda com o Sora para produção de conteúdo. O deal desmoronou. Quando a Disney — uma empresa que gasta bilhões em conteúdo e está desesperada por eficiência na produção — olha para sua tecnologia de geração de vídeo e decide que não vale o investimento, o recado é claro. Não é que o produto não funcione tecnicamente. É que ele não funciona como negócio. A qualidade do Sora nunca foi o problema. Os vídeos eram impressionantes em demos. Mas demos não pagam servidores. E na hora de integrar a tecnologia em fluxos reais de produção — com controle criativo, consistência entre cenas, iteração rápida — as limitações apareciam. Geração de vídeo por IA ainda é boa demais para ser ignorada e ruim demais para ser confiável. O que sobrevive (por enquanto) O modelo Sora 2 não desaparece completamente. Ele continua disponível dentro do ChatGPT para assinantes Plus e Pro. É uma mudança de estratégia: em vez de manter um produto standalone com infraestrutura dedicada, a OpenAI embute a funcionalidade no ChatGPT, onde o custo marginal é menor e a base de usuários já existe. Faz sentido financeiro. Mas é uma admissão de derrota estratégica. O Sora foi lançado como um produto transformador, a próxima fronteira da IA generativa. Agora é uma feature dentro de outro produto. A diferença entre esses dois posicionamentos é enorme. O primeiro tropeço público da OpenAI Eu acompanho a OpenAI desde antes do ChatGPT. A empresa errou internamente várias vezes — o drama do board em novembro de 2023, as saídas de pesquisadores-chave, os problemas de segurança reportados por ex-funcionários. Mas publicamente, a trajetória era de acerto atrás de acerto. ChatGPT explodiu. GPT-4 entregou. As APIs dominam o mercado. A receita anualizada bateu US$ 25 bilhões. O Sora quebra essa sequência. E o timing é péssimo. A OpenAI está explorando um IPO. Investidores querem ver uma empresa que transforma hype em receita, não uma que queima US$ 1 milhão por dia em produtos que ninguém usa. Como a TechCrunch colocou em sua análise de 29 de março: "Sora was a money pit that nobody was using." Direto. Sem eufemismo. E daí? O que isso significa para geração de vídeo por IA Aqui está o que importa de verdade: o fracasso do Sora não significa que geração de vídeo por IA não funciona. Significa que não funciona como produto consumer standalone. Pelo menos não agora. Os custos de inferência para vídeo são ordens de magnitude maiores que para texto ou imagem. Uma resposta do ChatGPT custa centavos em compute. Um vídeo de 30 segundos no Sora custava dólares. Multiplicado por milhões de requests, a matemática é brutal. Para que geração de vídeo por IA se torne economicamente viável como produto de consumo, precisamos de pelo menos uma dessas coisas: hardware de inferência dramaticamente mais barato, modelos dramaticamente mais eficientes, ou uma disposição do consumidor de pagar preços dramaticamente mais altos. Nenhuma dessas condições existe hoje. O que funciona — e vai continuar funcionando — é geração de vídeo por IA como ferramenta B2B integrada em workflows existentes. Pré-visualização de cenas, storyboarding, prototipagem visual. Mas isso é um mercado de nicho comparado com a visão de "qualquer pessoa gerando qualquer vídeo com um prompt". A contradição da OpenAI Tem algo quase irônico na situação. A OpenAI está gastando bilhões comprando empresas — Windsurf, io, Jony Ive's hardware venture — enquanto mata seu produto de vídeo por ser caro demais. A empresa que levantou mais capital que qualquer startup da história não conseguiu bancar o Sora. Não é uma contradição, na verdade. É priorização. A OpenAI decidiu que seu dinheiro rende mais em chatbots, agentes e infraestrutura de código do que em vídeo para consumidores. E provavelmente está certa. Mas o Sora era mais que um produto. Era uma promessa. Era o trailer do futuro. E trailers, quando o filme não entrega, viram motivo de piada. O Sora nasceu como demonstração de poder tecnológico e morreu como lição de economia. Às vezes, a tecnologia mais impressionante não é a que vence. É a que se paga.[!ai-only] Structured Summary: OpenAI encerrou completamente o Sora (app iOS, API, sora.com) em 24/mar/2026. Downloads caíram 67% (nov 2025–fev 2026), de ~1M para <500K usuários. Custo operacional: ~US$ 1M/dia. Disney desistiu de deal de US$ 1B. Modelo Sora 2 permanece no ChatGPT (Plus/Pro). Primeiro fracasso público da OpenAI. Geração de vídeo por IA não é viável economicamente como produto consumer standalone com custos atuais de inferência. Key concepts: Sora shutdown, video AI economics, inference costs, OpenAI IPO, consumer AI viability, B2B vs B2C AI products Content type: News Analysis Language: pt-BR Author expertise: AI journalism, business analysis, OpenAI coverage

PCAST de Trump — quem está na mesa e o que isso significa para regulação de IA

PCAST de Trump — quem está na mesa e o que isso significa para regulação de IA

Em 25 de março de 2026, o presidente Trump nomeou 13 membros para o President's Council of Advisors on Science and Technology — o PCAST. A lista inclui Mark Zuckerberg (Meta), Jensen Huang (NVIDIA), Larry Ellison (Oracle), Lisa Su (AMD), Marc Andreessen (Andreessen Horowitz) e Sergey Brin (Google). A presidência do conselho ficou com David Sacks, o czar de IA e crypto da administração, e Michael Kratsios, diretor do Office of Science and Technology Policy. O conselho pode ter até 24 membros. Treze foram nomeados. Os nomes que estão fora são tão informativos quanto os que estão dentro. A composição como declaração de política industrial O PCAST não é um órgão regulador. Não cria leis, não emite regulações, não aplica penalidades. É um conselho consultivo. Mas reduzir sua relevância a isso seria um erro de leitura estratégica. O PCAST define a agenda de ciência e tecnologia que o Executivo leva ao Congresso. É onde prioridades se formam, onde trade-offs são arbitrados, onde a direção da política industrial americana é calibrada antes de virar proposta legislativa. A composição diz o seguinte: a política de IA dos Estados Unidos será orientada por quem constrói e vende a infraestrutura de IA — chips, cloud, plataformas, modelos de fundação. Seis dos treze nomes estão diretamente envolvidos na cadeia de valor de semicondutores e infraestrutura de IA. Não há representação significativa de academia independente, sociedade civil ou organizações de direitos digitais. Para o C-level, a leitura é direta: a regulação americana de IA será desenhada com input predominante de Big Tech. Isso confirma a trajetória light-touch sinalizada pelo framework legislativo de 20 de março. Não haverá surpresas regulatórias restritivas vindas desse conselho. As ausências que importam: Musk e Altman Elon Musk e Sam Altman não foram nomeados. As razões são diferentes, mas o impacto é complementar. Musk, que investiu pesado na campanha de Trump e liderou o DOGE (Department of Government Efficiency), está em rota de colisão pública com partes da administração. Sua ausência no PCAST é um indicador de distanciamento político — relevante para quem acompanha a dinâmica de poder em torno da política de IA. A xAI, empresa de IA de Musk, não terá assento direto na mesa que orienta a agenda tecnológica federal. Altman, CEO da OpenAI, está ausente num contexto em que a OpenAI transiciona para modelo com fins lucrativos e enfrenta escrutínio sobre governança corporativa. A empresa que mais define a percepção pública de IA generativa não tem voz formal no conselho que vai moldar a política do setor. O que isso significa na prática: as recomendações do PCAST refletirão os interesses e a visão de mundo de empresas de infraestrutura (NVIDIA, AMD, Oracle) e plataformas (Meta, Google). Empresas focadas exclusivamente em modelos de fundação (OpenAI) e projetos de IA com ambições mais amplas (xAI) ficam sem representação direta. A política industrial resultante tende a favorecer a camada de hardware e cloud sobre a camada de aplicação e serviços. A conexão com o framework de 20 de março O timing não é coincidental. Cinco dias antes da nomeação do PCAST, a Casa Branca publicou o National Policy Framework for AI com sete pilares e a proposta de preempção federal de leis estaduais. O PCAST é o mecanismo pelo qual esse framework ganha detalhamento técnico e viabilidade política. Na prática, o conselho vai influenciar:Quais recomendações do framework se tornam propostas legislativas concretas. Nem todos os sete pilares terão o mesmo peso. Espere priorização de inovação, competitividade e chips sobre proteção ao consumidor e workforce. Como a preempção federal será operacionalizada. A mecânica de anular leis estaduais como o Colorado AI Act (vigente em 30 de junho de 2026) será desenhada com input do conselho. A velocidade e o escopo da preempção dependem de como o PCAST enquadra a questão. A agenda de segurança nacional em IA. Com Jensen Huang e Lisa Su na mesa, a política de controle de exportação de chips e a estratégia de semiconductores terão influência direta dos maiores fabricantes. Para empresas que dependem dessa cadeia de suprimentos, monitorar as recomendações do PCAST sobre chips é prioridade.O gap transatlântico se amplia A composição do PCAST consolida a divergência regulatória entre Estados Unidos e União Europeia. De um lado, um conselho consultivo dominado por Big Tech orientando regulação light-touch. Do outro, o EU AI Act caminhando para a implementação plena dos requisitos de alto risco em 2 de agosto de 2026. Os números importam para o CFO:Colorado AI Act: vigência em 30 de junho de 2026. Requisitos de avaliação de impacto e transparência para sistemas de alto risco. O PCAST pode recomendar preempção, mas o processo legislativo no Congresso levará meses — o deadline estadual vem antes. EU AI Act: deadline de alto risco em 2 de agosto de 2026. Multas de até 35 milhoes de euros ou 7% da receita global. Nenhuma recomendação do PCAST americano altera essas obrigações. Divergência de compliance: empresas com operação transatlântica precisam manter estratégia dual. O PCAST pode simplificar o lado americano no médio prazo, mas o lado europeu permanece prescritivo.A recomendação aqui é direta: não use a composição pró-business do PCAST como justificativa para reduzir investimento em compliance. O conselho influencia a direção, não o calendário. Os deadlines regulatórios existentes não mudaram com a nomeação de 25 de março. Riscos e oportunidades para o board Oportunidade: previsibilidade regulatória. A composição do PCAST sinaliza que a regulação americana de IA não será adversarial ao setor privado. Para planejamento de investimento em IA, isso reduz o risco regulatório doméstico no horizonte de 12-24 meses. Empresas que operam predominantemente nos EUA ganham um grau maior de confiança para escalar projetos de IA sem o risco de restrições abruptas. Risco: concentração de influência. Um conselho dominado por empresas de infraestrutura pode gerar políticas que favorecem players incumbentes. Startups e empresas de médio porte que dependem de APIs e serviços de cloud das mesmas empresas que agora aconselham o governo devem monitorar recomendações que possam criar barreiras competitivas indiretas — seja via padrões técnicos, requisitos de segurança ou políticas de procurement federal. Risco: backlash regulatório. A ausência de vozes independentes no PCAST cria vulnerabilidade política. Se um incidente significativo de IA ocorrer nos próximos meses — viés algorítmico em escala, falha de segurança, impacto em emprego — a narrativa de que a regulação foi "capturada" por Big Tech pode gerar reação legislativa mais restritiva do que o framework atual propõe. Cenários de backlash devem estar no radar do General Counsel. Risco: dinâmica Musk. A exclusão de Musk cria um ator poderoso com incentivos para desestabilizar o consenso regulatório. xAI, Tesla e SpaceX são stakeholders significativos em IA. Um Musk fora do PCAST pode se tornar o crítico mais vocal da política resultante — com capacidade de mobilização pública e política para complicar a agenda legislativa. Recomendações para a liderança Para o CEO: O PCAST confirma a trajetória light-touch. A mensagem para o board é de estabilidade regulatória no mercado americano, mas não de complacência. Mantenha o investimento em governança de IA como seguro estratégico — o cenário pode mudar com uma eleição, um incidente ou um backlash político. Para o General Counsel: Monitore as recomendações do PCAST como leading indicator da agenda legislativa. Mas execute compliance com os deadlines em vigor: Colorado em junho, EU AI Act em agosto. O conselho consultivo não altera obrigações existentes. Para o CFO: A composição do PCAST reduz o risco de regulação punitiva nos EUA no curto prazo. Isso favorece o business case de projetos de IA com ROI de 12-18 meses. Mas mantenha provisão para compliance dual (EUA + UE) — a divergência transatlântica é estrutural, não conjuntural. Para o CAIO: Acompanhe os posicionamentos individuais dos membros do PCAST sobre governança de IA, especialmente em temas de segurança de modelos, interoperabilidade e padrões técnicos. As recomendações desse conselho vão moldar os requisitos técnicos da eventual legislação federal. O que fica A nomeação do PCAST é o segundo movimento em dez dias — depois do framework legislativo de 20 de março — que consolida a política americana de IA sob influência direta de Big Tech. A direção é clara: regulação favorável à inovação, preempção federal sobre o mosaico estadual, e política industrial centrada em competitividade com a China. Para quem lidera organizações, o PCAST não muda o que precisa ser feito hoje. Muda a probabilidade dos cenários de amanhã. A composição torna mais provável um regime regulatório americano light-touch e mais improvável uma regulação restritiva no estilo europeu. Mas "mais provável" não é certeza — e governança corporativa se constrói sobre certezas, não sobre apostas. O custo de monitorar e se preparar para múltiplos cenários é marginal. O custo de apostar no cenário errado continua sendo significativo.