A Inteligência Artificial deixou de ser uma promessa distante para se tornar uma ferramenta concreta de transformação em áreas essenciais da sociedade. Na saúde, esse movimento é ainda mais relevante, porque envolve vidas, tempo de atendimento, qualidade na triagem, apoio aos profissionais e proteção de dados extremamente sensíveis. É nesse contexto que nasce a IA MED, uma solução desenvolvida pela MultiCortex para levar modelos avançados de linguagem ao setor de saúde com foco em precisão, privacidade, eficiência operacional e soberania tecnológica.

A IA MED já está em funcionamento na cidade de Bebedouro, interior de São Paulo, cidade natal de Alessandro de Oliveira Faria, também conhecido como Cabelo, fundador da MultiCortex. A implantação tem um significado especial: além de representar um avanço tecnológico para a rede municipal de saúde, simboliza o retorno de décadas de pesquisa, desenvolvimento e inovação para beneficiar diretamente a população da cidade onde nasceu o idealizador da solução.

Segundo publicação oficial da Prefeitura Municipal de Bebedouro, a tecnologia IAmed foi desenvolvida pelo bebedourense e tem como objetivo auxiliar os profissionais de saúde no dia a dia, contribuindo para mais agilidade, precisão e qualidade nos atendimentos prestados à população. A Prefeitura também informa que a ferramenta foi cedida gratuitamente ao município pela MultiCortex IA, com infraestrutura Magalu Cloud, para acelerar e fomentar o uso de IA na saúde pública local.

A proposta da IA MED parte de uma preocupação muito concreta: ferramentas genéricas de Inteligência Artificial generativa, especialmente aquelas hospedadas em nuvens internacionais, não foram concebidas originalmente para lidar com a complexidade, a responsabilidade e a sensibilidade dos dados de saúde pública brasileira. Em um ambiente clínico, dados pessoais, históricos médicos, sintomas, exames, hipóteses, encaminhamentos e informações familiares não podem ser tratados como simples entradas de texto em uma aplicação qualquer. Eles exigem governança, segurança, rastreabilidade, controle de acesso e conformidade com a legislação brasileira.

A Lei Geral de Proteção de Dados Pessoais, a LGPD, estabelece regras para o tratamento de dados pessoais, inclusive em meios digitais, com o objetivo de proteger direitos fundamentais como liberdade, privacidade e livre desenvolvimento da personalidade. A própria legislação brasileira classifica dados referentes à saúde como dados pessoais sensíveis, o que torna ainda mais importante a adoção de arquiteturas tecnológicas que reduzam exposição, transferência desnecessária e dependência de ambientes fora do controle da organização pública ou privada.

Por isso, a IA MED foi pensada como uma Inteligência Artificial privada, verticalizada e adequada ao contexto da saúde. Diferente de IAs genéricas, que tentam responder sobre qualquer assunto a partir de modelos amplos e de uso geral, a IA MED trabalha com modelos de linguagem especializados, ajustados para fluxos, protocolos, terminologias e necessidades do setor de saúde. Essa verticalização permite maior aderência ao domínio médico-assistencial e reduz a dependência de respostas genéricas, vagas ou pouco contextualizadas.

Na prática, isso significa que a IA MED não existe para substituir médicos, enfermeiros, técnicos ou gestores de saúde. Pelo contrário: ela foi criada para apoiar esses profissionais. O papel da Inteligência Artificial é atuar como uma camada de auxílio, ajudando na organização das informações, na análise de dados clínicos disponíveis, na identificação de riscos, na triagem de prioridades, na sugestão de caminhos com base em protocolos e na redução de tarefas burocráticas que consomem tempo das equipes.

Nas Unidades Básicas de Saúde, onde a demanda é constante e os profissionais precisam lidar com grande volume de atendimentos, a IA pode se tornar uma aliada estratégica. Ela pode ajudar a estruturar informações do paciente, facilitar o acesso ao histórico, apoiar a classificação de risco, sugerir perguntas relevantes durante uma triagem, organizar encaminhamentos e permitir que a equipe tenha uma visão mais clara do fluxo de atendimento. Com isso, o profissional de saúde ganha tempo, reduz carga mental e pode se concentrar mais no cuidado humano.

Essa é uma das maiores contribuições da IA MED: usar tecnologia não para afastar o paciente do profissional, mas para devolver tempo ao atendimento humanizado. A saúde pública enfrenta desafios diários de volume, urgência, documentação, filas, registros e priorização. Quando uma ferramenta de IA bem desenhada assume parte do trabalho repetitivo e auxilia na organização das informações, ela contribui para que médicos e enfermeiros possam tomar decisões com mais segurança e menos sobrecarga.

Outro diferencial importante da IA MED está no custo computacional. Muitos projetos de Inteligência Artificial são inviabilizados porque dependem de servidores extremamente caros, como máquinas baseadas em GPUs H100 ou B200, que podem representar investimentos muito altos em infraestrutura. A proposta da MultiCortex é demonstrar que, com engenharia especializada, otimização de modelos, verticalização e uso inteligente de hardware, é possível entregar uma solução de IA aplicada à saúde utilizando infraestrutura com custo muito inferior na ordem de aproximadamente 10% do valor de grandes servidores baseados nessas GPUs topo de linha (GRAÇAS A COMPUTAÇÃO HETEROGÊNEA).

Essa diferença de custo é fundamental para a realidade brasileira. A inovação não pode ficar restrita a grandes centros, grandes hospitais ou instituições com orçamentos milionários. A Inteligência Artificial precisa ser viável para municípios, unidades públicas, clínicas, secretarias e organizações que buscam modernização, mas precisam respeitar limites financeiros. A IA MED nasce justamente dessa visão: criar uma tecnologia de alto impacto, com custo mais acessível e aplicação prática no cotidiano da saúde

A parceria com a Magalu Cloud reforça outro ponto central do projeto: a soberania dos dados. A Magalu Cloud se apresenta como uma nuvem brasileira, com preços em reais, suporte em português, infraestrutura local e data centers fisicamente no Brasil, distribuídos nas regiões Sudeste e Nordeste. A empresa também destaca que os dados são armazenados localmente e em conformidade com a legislação brasileira.

Para aplicações de saúde, esse detalhe é decisivo. Utilizar infraestrutura em território nacional reduz riscos associados à transferência internacional de dados, melhora a previsibilidade regulatória e aproxima a operação da realidade jurídica, técnica e institucional do Brasil. Em vez de depender exclusivamente de nuvens estrangeiras, cobradas em dólar e sujeitas a camadas adicionais de complexidade contratual e regulatória, a IA MED utiliza uma infraestrutura alinhada ao conceito de soberania digital.

A Magalu Cloud também destaca benefícios como preços em reais, previsibilidade sem variação cambial, suporte humano em português, infraestrutura local, baixa latência, custos reduzidos, escalabilidade e serviços como máquinas virtuais, armazenamento, VPC, Kubernetes, banco de dados e ferramentas de identidade e acesso. Para um projeto como a IA MED, esses elementos ajudam a compor uma base tecnológica mais adequada para o setor público brasileiro.

Além da privacidade, há também a questão da previsibilidade de custos. Muitas soluções de IA em nuvem funcionam com cobrança baseada em tokens, o que pode se tornar um problema quando há grande volume de atendimentos, consultas, registros e interações. Em ambientes públicos, onde orçamento precisa ser planejado e justificado, custos variáveis e imprevisíveis podem dificultar a adoção em escala. A IA MED busca reduzir esse problema ao operar em uma arquitetura mais controlada, privada e otimizada, sem depender do modelo tradicional de cobrança por token de plataformas externas.

Essa abordagem permite que a Inteligência Artificial deixe de ser uma despesa imprevisível e passe a ser uma infraestrutura estratégica. Em vez de pagar indefinidamente por cada interação processada em serviços de terceiros, a organização pode trabalhar com um ambiente mais previsível, controlado e adaptado à sua demanda. Para a saúde pública, isso significa maior capacidade de planejamento, menor dependência externa e mais sustentabilidade para expandir o uso da tecnologia.

O impacto para a população pode ser percebido de várias formas. O cidadão tende a se beneficiar de atendimentos mais organizados, triagens mais ágeis, melhor acompanhamento, redução de retrabalho e maior apoio à identificação de prioridades. Em muitos casos, a diferença não estará apenas em “usar IA”, mas em usar IA para melhorar processos invisíveis que afetam diretamente a experiência do paciente: tempo de espera, clareza das informações, encaminhamentos, continuidade do cuidado e segurança no atendimento.

Para os profissionais de saúde, a IA MED representa uma ferramenta de apoio em um cenário de alta responsabilidade. O cansaço mental, a pressão por produtividade, a repetição de tarefas administrativas e o volume de informações podem aumentar a margem de erro em qualquer setor. Na saúde, porém, erros podem ter consequências graves. A Inteligência Artificial, quando aplicada com responsabilidade, pode ajudar a mitigar riscos, organizar dados e apoiar decisões, sempre mantendo o profissional humano no centro do processo.

A iniciativa em Bebedouro também carrega um valor simbólico importante. Ver uma tecnologia criada por um bebedourense sendo aplicada diretamente em benefício da população local mostra que inovação não precisa nascer apenas em polos internacionais ou grandes capitais. A inovação também pode surgir do interior, de trajetórias individuais de pesquisa, de comunidades técnicas brasileiras e de empresas que entendem os desafios reais do país.

Para Alessandro de Oliveira Faria, a implantação da IA MED em Bebedouro representa mais do que um projeto tecnológico. É o resultado de mais de 25 anos de pesquisa em Inteligência Artificial, iniciada ainda em 1998, somada a uma trajetória dedicada à computação de alto desempenho, otimização de hardware, software livre e aplicação prática da tecnologia em benefício da sociedade. Levar essa experiência para a saúde pública da sua cidade natal é uma forma de transformar conhecimento acumulado em impacto social direto.

Durante a fase de avaliação, a MultiCortex disponibilizou o sistema gratuitamente ao município de Bebedouro por meio de um termo de cooperação com a Prefeitura. A empresa assumiu integralmente os custos computacionais em nuvem, reforçando o compromisso de manter Bebedouro na vanguarda da inovação tecnológica. A iniciativa remete ao histórico da cidade com projetos pioneiros de tecnologia, como ocorreu no início dos anos 2000 com a implantação da biometria de impressão digital.

Esse ponto é essencial: inovação pública não acontece apenas quando se compra tecnologia pronta. Ela acontece quando há colaboração entre poder público, empresas, pesquisadores, profissionais técnicos e a comunidade. Ao ceder a IA MED gratuitamente na fase de avaliação, a MultiCortex cria uma oportunidade concreta para que a cidade experimente, valide e compreenda os benefícios da Inteligência Artificial aplicada à saúde de forma segura, responsável e alinhada à realidade local.

A IA MED também reforça uma visão maior da MultiCortex: devolver às organizações o controle sobre sua própria Inteligência Artificial. No setor da saúde, esse controle é ainda mais importante. Não se trata apenas de desempenho técnico, mas de governança, soberania, privacidade e responsabilidade. Uma IA aplicada à saúde precisa respeitar dados, pessoas, profissionais e instituições. Precisa ser explicável dentro do possível, auditável, segura e construída para o contexto em que será usada.

Ao unir modelos de LLM verticalizados, infraestrutura nacional, custo computacional reduzido, privacidade e foco no apoio aos profissionais de saúde, a IA MED se posiciona como uma alternativa brasileira para um dos maiores desafios da atualidade: como usar Inteligência Artificial em áreas sensíveis sem abrir mão da segurança, da ética e da soberania dos dados.

Bebedouro, ao receber essa implantação, dá um passo importante rumo à modernização dos serviços públicos de saúde. A iniciativa mostra que a tecnologia pode ser uma aliada direta do cuidado, não apenas uma ferramenta distante de laboratório. Mostra também que a IA pode ser aplicada de forma responsável, com foco em pessoas, em eficiência pública e na valorização dos profissionais que estão na linha de frente.

A IA MED nasce com esse propósito: transformar a Inteligência Artificial em uma infraestrutura confiável para a saúde, capaz de apoiar decisões, otimizar processos, reduzir custos e proteger dados sensíveis. Mais do que uma ferramenta tecnológica, ela representa uma visão de futuro para a saúde pública brasileira, um futuro em que inovação, privacidade, soberania e cuidado humano caminham juntos.

A Inteligência Artificial já consegue conversar, transcrever áudio, narrar livros, atender clientes e criar assistentes de voz. Mas existe um problema que ainda passa despercebido: muitas dessas tecnologias não entendem o Brasil como ele realmente fala. O português brasileiro não é uma voz única, neutra e padronizada. Ele é caipira, baiano, nortista, gaúcho, mineiro, carioca, paulistano, nordestino, amazônico, interiorano, urbano e profundamente diverso.

É exatamente para enfrentar esse desafio que nasce o SOTAQUE — Speech-Oriented Training Audio for Quality Understanding and Expression, uma iniciativa voltada à criação de um dataset aberto de vozes em português brasileiro, com foco na diversidade regional dos sotaques do país. A proposta é simples e poderosa: reunir vozes reais de brasileiros para que tecnologias de fala, como assistentes virtuais, audiobooks, sistemas de transcrição automática e modelos de voz, consigam representar melhor a pluralidade do nosso idioma.

Meus mais sinceros
parabéns Fabrício Carraro!

Hoje, muitos modelos de fala em português ainda são treinados com pouca diversidade de vozes, muitas vezes concentradas em sotaques urbanos do Sudeste, especialmente paulistano e carioca. Isso faz com que uma IA fale português de forma artificialmente neutra e, em alguns casos, tenha dificuldade para compreender pessoas com sotaques regionais mais marcados. O resultado é uma tecnologia que funciona melhor para alguns brasileiros do que para outros

O SOTAQUE quer mudar essa realidade por meio de uma construção coletiva. A ideia é criar uma base pública, documentada e aberta, feita com contribuições voluntárias da comunidade. Cada pessoa pode ajudar enviando um áudio com sua própria voz e respondendo algumas perguntas rápidas sobre seu perfil linguístico, como região onde cresceu, estado, sotaque declarado e faixa etária. O processo leva poucos minutos e pode ser feito com uma gravação nova ou até com um áudio antigo, desde que respeite as regras do projeto.

A importância desse projeto vai além da tecnologia. Ele toca em representatividade linguística. Quando um sotaque fica fora dos datasets, milhões de pessoas também ficam menos representadas nas ferramentas digitais que escutam, falam, transcrevem e interagem em português. Ter uma IA que entende melhor o Brasil é também garantir que a inovação não apague as nossas diferenças regionais, mas aprenda com elas.

Outro ponto relevante é que o projeto nasce com uma proposta aberta. As gravações, transcrições e metadados autorizados serão publicados com licença CDLA-Permissive-2.0, permitindo uso amplo por pesquisadores, startups, escolas, criadores de conteúdo e desenvolvedores interessados em tecnologias de fala em português brasileiro. A meta inicial do projeto é alcançar 1.000 horas de áudio coletado e curado, com uma meta final de 10.000 horas.

Naturalmente, quando falamos de voz, também falamos de privacidade. O próprio termo do projeto deixa claro que a participação é voluntária, restrita a maiores de 18 anos localizados no Brasil no momento da contribuição, e que a pessoa deve contribuir apenas com a própria voz. Também é importante evitar áudios com dados pessoais de terceiros, senhas, informações financeiras ou qualquer conteúdo sensível.

O SOTAQUE é uma oportunidade para a comunidade brasileira participar diretamente da construção de tecnologias mais justas, abertas e representativas. Em vez de esperar que grandes empresas definam sozinhas como a IA deve falar português, podemos contribuir com a nossa própria voz para que os próximos modelos entendam melhor quem somos, de onde viemos e como falamos.

Contribuir é simples, vá até a página Contribuir e envie um áudio com sua voz (Leva uns 2 minutos: granvando um áudio, conta um pouco sobre você, marca o consentimento. Pronto), ajude a construir um dataset aberto que pode beneficiar toda a comunidade de IA, educação, acessibilidade, pesquisa e inovação no Brasil. A sua voz tem valor. O seu sotaque também.

Mais informações aqui: https://sotaque.ia.br/

O AutoRound (https://github.com/intel/auto-round) é uma ferramenta de quantização para LLMs e VLMs desenvolvida pela Intel. A ideia central é reduzir o modelo para 2, 3, 4 ou 8 bits, mantendo boa precisão, principalmente em cenários de low-bit weight-only quantization (converte os pesos mas manter a inferência), como W4A16, W3A16 e W2A16. O próprio repositório descreve o AutoRound como um toolkit para LLMs/VLMs que usa signed gradient descent para obter alta acurácia em 2–4 bits com baixo custo de ajuste.

Como Intel Innovator, tenho a missão mostrar o compromisso sério da Intel neste vertical tecnológica. A tecnologia beneficia GPU NVIDIA, CPU e XPU

Em termos simples: ele não apenas “arredonda” os pesos para 4 bits como um método ingênuo faria. Ele aprende a melhor forma de arredondar os pesos e também ajusta os limites de clipping para reduzir o erro entre a saída do bloco original e a saída do bloco quantizado. O paper do SignRound (https://arxiv.org/html/2309.05516v3) explica que o método adiciona parâmetros treináveis para ajustar o rounding e dois parâmetros extras para ajustar o clipping dos pesos; depois usa reconstrução por bloco e otimização com SignSGD.

Como ele funciona

O fluxo é mais ou menos assim:

1. Você passa um modelo Hugging Face, por exemplo Qwen/Qwen3-0.6B, Llama, Mistral, etc.
2. Ele usa um dataset de calibração. Por padrão, usa NeelNanda/pile-10k, mas aceita datasets customizados, JSON local, lista de strings, input ids, concatenação de datasets e aplicação de chat template.
3. Para cada bloco/camada, ele compara a saída do modelo original com a saída do modelo quantizado.
4. Ele otimiza o rounding dos pesos e o range de clipping usando signed gradient descent.
5. No final, salva o modelo em um formato escolhido: auto_round, auto_gptq, auto_awq, gguf, llm_compressor, mlx, entre outros.

Como usar?

pip install auto-round
auto-round \
--model Qwen/Qwen3-0.6B \
--scheme "W4A16" \
--format "auto_round" \
--output_dir ./qwen_autoround_w4a16

Para exportar para GGUF:

auto-round \
--model Qwen/Qwen3-0.6B \
--format "gguf:q4_k_m" \
--output_dir ./qwen_gguf_q4_k_m

O repositório mostra instalação via pip install auto-round, suporte a CPU/GPU CUDA, Intel XPU e Gaudi/HPU, além de exemplos com Qwen/Qwen3-0.6B

O que significa W4A16, W3A16, W2A16

W4A16 significa:

O AutoRound documenta esquemas como W4A16, W8A16, W3A16, W2A16, mixed bits, GGUF, NVFP4, MXFP4, FP8 e outros.

Na prática, W4A16 costuma ser o ponto mais seguro: boa redução de memória com perda pequena. W2A16 é muito mais agressivo: pode reduzir muito mais o tamanho dos pesos, mas exige algoritmo melhor, calibração melhor e validação forte.

Diferença para GPTQ, AWQ, SmoothQuant, bitsandbytes e GGUF

GPTQ se baseia em quantização weight-only com informação aproximada de segunda ordem e mostrou bons resultados em 3/4 bits em modelos grandes. AWQ usa estatísticas de ativação para proteger canais salientes e evitar quantização mista ineficiente, sem backpropagation ou reconstrução. SmoothQuant é uma abordagem PTQ para W8A8, suavizando outliers de ativação por uma transformação matematicamente equivalente entre ativações e pesos. bitsandbytes fornece camadas quantizadas 8-bit/4-bit, otimizadores 8-bit, LLM.int8() e QLoRA com NF4 para reduzir uso de memória.

Vantagens do AutoRound

A grande vantagem é que ele tenta entregar mais qualidade em baixa precisão, principalmente em 2, 3, 4 e 8 bits, onde métodos simples como RTN geralmente degradam bastante. No paper original, os autores comparam com GPTQ, AWQ, HQQ, OmniQuant e RTN, e relatam ganhos maiores conforme os bits diminuem, especialmente em W2G128, com melhorias absolutas de acurácia média entre 6,91% e 33,22% em 11 tarefas zero-shot.

Outra vantagem é a compatibilidade de ecossistema: o AutoRound suporta exportação para auto_round, auto_gptq, auto_awq, gguf, llm_compressor e mlx, além de integração com Transformers, vLLM e SGLang.

Dicas:

# equilíbrio entre qualidade e custo
auto-round --model Qwen/Qwen3-0.6B --scheme "W4A16"
# melhor qualidade, mais lento
auto-round-best --model Qwen/Qwen3-0.6B --scheme "W4A16"
# mais rápido, com possível perda de acurácia
auto-round-light --model Qwen/Qwen3-0.6B --scheme "W4A16"

A documentação recomenda auto-round como bom equilíbrio geral, auto-round-best para melhor acurácia — especialmente 2-bit — e auto-round-light para velocidade, mais indicado em 4-bit e modelos maiores que 3B.

O AutoRound não elimina a necessidade de benchmark real. Quantização muda o comportamento do modelo, e a perda pode aparecer em raciocínio, código, português, instruções longas ou domínios específicos. Para um modelo que você usa em produção, eu validaria pelo menos:

# exemplo conceitual
lm_eval \
--model hf \
--model_args pretrained=./qwen_autoround_w4a16 \
--tasks hellaswag,arc_challenge,mmlu,truthfulqa \
--batch_size auto

Também é importante entender que W4A16 quantiza principalmente os pesos, mantendo ativações em 16 bits. Isso reduz muito o tamanho do modelo, mas não resolve sozinho todos os gargalos, por exemplo KV-cache em contextos longos. O paper original deixa claro que o foco experimental era weight-only quantization em camadas lineares dos blocos transformer.

Outro ponto: alguns esquemas novos, como MXFP4/MXINT4/MXFP8, aparecem na documentação como recursos de pesquisa ou sem kernel real em certos casos; então o formato escolhido precisa casar com o runtime que você vai usar.

Minha leitura particular: AutoRound é uma das opções mais interessantes hoje para quantização low-bit de LLMs quando qualidade importa mais do que apenas velocidade de conversão. Para W4A16, eu testaria como alternativa séria a GPTQ/AWQ. Para W2A16, eu priorizaria AutoRound/SignRound, mas sempre com avaliação no seu conjunto de tarefas.

Código fonte: https://github.com/intel/auto-round

Copy Fail (CVE-2026-31431) é uma vulnerabilidade de escalonamento local de privilégio no kernel Linux QUE TOMOU CONTA DAS REDES SOCIAIS. Ela foi divulgada publicamente em 29 de abril de 2026 e está ligada ao subsistema criptográfico do kernel, especialmente à interface AF_ALG / algif_aead e ao template criptográfico authencesn. Em termos práticos: um usuário local sem privilégios pode abusar de uma falha lógica para fazer uma escrita controlada de poucos bytes no page cache de um arquivo legível e, a partir disso, alterar o comportamento de binários privilegiados para obter root.

O conceito central é que o kernel permite que programas em userspace usem algoritmos criptográficos via sockets AF_ALG. A falha apareceu em uma lógica de operação “in-place” em AEAD, isto é, quando a origem e o destino da operação criptográfica são tratados de forma inadequada como se pudessem compartilhar o mesmo espaço/mapeamento. O patch oficial basicamente remove essa complexidade e volta a operar “out-of-place”, porque não havia benefício real em operar in-place nesse caso.

O nome Copy Fail vem justamente dessa ideia: uma cópia que deveria cair em um destino seguro acaba afetando um local errado/controlável. A exploração pública descreve uma cadeia envolvendo AF_ALG, splice(), page cache e uma escrita controlada de 4 bytes em arquivo legível. Isso é perigoso porque muitos binários privilegiados do sistema, como su, sudo, pkexec, passwd, mount, chsh e chfn, normalmente são executáveis setuid-root e, em várias distribuições, também são legíveis por usuários comuns.

O impacto é alto porque não é uma exploração remota: o atacante precisa ter acesso local ao sistema, por exemplo uma conta shell, usuário em servidor compartilhado, container mal isolado ou ambiente multiusuário. Mas, uma vez dentro, a falha pode permitir virar root sem depender de race condition, offsets específicos por distribuição ou tentativas instáveis. Os pesquisadores afirmam ter testado em Ubuntu, Amazon Linux, RHEL e SUSE, incluindo SUSE 16.

Nós como membros da OWASP Capítulo São Paulo, temos a missão de ajudar a mitigar este problema…

A mitigação principal e correta é atualizar o kernel para uma versão que contenha o patch/revert de algif_aead. A mitigação com chmod é uma defesa emergencial: ela reduz a superfície de ataque removendo permissão de leitura de binários setuid sensíveis, mantendo a execução e o bit setuid. Então abaixo o comando de autoria do Raphael Bastos A.K.A. coffnix para executar o chmod removendo o direito de leitura dos comandos passwd chsh chfn mount sudo pkexec

for b in passwd chsh chfn mount sudo su pkexec; 
   do p=$(readlink -f "$(command -v "$b")"); 
   [ -n "$p" ] && chmod 4711 "$p"; done

O brinquedo funciona assim: ele percorre a lista de binários sensíveis (passwd, chsh, chfn, mount, sudo, pkexec), encontra o caminho real de cada um com command -v e readlink -f, e aplica chmod 4711 no arquivo encontrado.

O modo 4711 significa:

4 = ativa o bit setuid
7 = dono/root pode ler, escrever e executar
1 = grupo só pode executar
1 = outros usuários só podem executar

Ou seja, o binário continua funcionando como setuid-root, mas deixa de ser legível por usuários comuns. Como a exploração depende de atingir arquivos legíveis no page cache, remover a permissão de leitura desses binários dificulta ou bloqueia essa cadeia específica contra esses alvos.

Em sistemas de produção, eu usaria assim:

sudo sh -c 'for b in passwd chsh chfn mount sudo pkexec; do p=$(readlink -f "$(command -v "$b")"); [ -n "$p" ] && chmod 4711 "$p"; done'

Depois valide:

ls -l /usr/bin/passwd /usr/bin/chsh /usr/bin/chfn /usr/bin/mount /usr/bin/sudo /usr/bin/pkexec

Você deve ver algo parecido com:

-rws--x--x root root ...

Resumo: patch de kernel é a correção real; chmod 4711 nos binários setuid é uma mitigação rápida para reduzir o alvo explorável enquanto o kernel corrigido não é aplicado.

O lançamento do Origin Pilot representa um marco importante na evolução da computação quântica, não apenas pelo avanço tecnológico em si, mas pela mudança estratégica que propõe na forma como sistemas quânticos são desenvolvidos, integrados e disponibilizados ao mundo. Trata-se de uma iniciativa que vai além das tradicionais bibliotecas ou frameworks de programação quântica, posicionando-se como uma camada fundamental da infraestrutura, o sistema operacional responsável por orquestrar toda a interação entre hardware quântico e sistemas clássicos.

O Origin Pilot, desenvolvido pela empresa chinesa Origin Quantum, foi disponibilizado publicamente como software open source, algo inédito no contexto de sistemas operacionais quânticos. Essa abertura marca uma ruptura com o modelo tradicional, onde o controle do stack tecnológico quântico desde o hardware até o software permanece fechado e altamente proprietário. Ao permitir o download e uso livre do sistema, a iniciativa busca reduzir barreiras de entrada e acelerar a adoção global da computação quântica, especialmente por universidades, startups e centros de pesquisa que não possuem infraestrutura completa própria.

Diferentemente de ferramentas como Qiskit ou Cirq, que operam em níveis mais altos da pilha tecnológica, o Origin Pilot atua em uma camada mais profunda: a de integração e gerenciamento do sistema. Ele funciona como um intermediário entre diferentes tipos de hardware quântico como qubits supercondutores, íons aprisionados e átomos neutros e os aplicativos desenvolvidos pelos usuários. Essa abordagem permite a criação de um ambiente unificado capaz de lidar com a heterogeneidade dos dispositivos quânticos, um dos maiores desafios atuais da área.

Do ponto de vista técnico, o sistema incorpora funcionalidades essenciais para o funcionamento eficiente de computadores quânticos. Entre elas estão o agendamento de tarefas quânticas, a alocação de qubits, a calibração automática dos sistemas e a execução paralela de múltiplos programas quânticos. Essas capacidades são críticas em ambientes NISQ (Noisy Intermediate-Scale Quantum), onde os recursos são limitados e altamente sensíveis a erros. O Origin Pilot também promove a integração entre computação clássica e quântica, permitindo pipelines híbridos que combinam CPUs, GPUs e QPUs em um mesmo fluxo de processamento.

Outro aspecto relevante é a capacidade do sistema de lidar com problemas específicos da computação quântica que não existem no mundo clássico. Questões como decoerência, ruído quântico e necessidade constante de recalibração exigem mecanismos sofisticados de controle em tempo real. O Origin Pilot incorpora algoritmos e estratégias voltadas para esses desafios, como o mapeamento eficiente de qubits e a otimização da fidelidade dos circuitos quânticos, garantindo melhor aproveitamento dos recursos disponíveis.

A proposta do Origin Pilot também carrega implicações estratégicas e geopolíticas. Ao disponibilizar gratuitamente uma camada de integração que ainda não possui equivalente aberto no Ocidente, a China pode influenciar diretamente o padrão de desenvolvimento global da computação quântica. Instituições ao redor do mundo podem optar por adotar esse sistema como base para seus projetos, o que, ao longo do tempo, cria um ecossistema dependente das abstrações, interfaces e arquiteturas definidas pela plataforma. Essa dinâmica lembra movimentos recentes no campo da inteligência artificial, onde a abertura de modelos e ferramentas levou à rápida expansão de determinados ecossistemas tecnológicos.

Além disso, o Origin Pilot faz parte de um esforço mais amplo de construção de uma infraestrutura quântica completa, que inclui hardware próprio, plataformas de nuvem quântica e ferramentas de desenvolvimento. Essa abordagem verticalizada busca reduzir a dependência de tecnologias estrangeiras e consolidar uma cadeia de valor autossuficiente. A disponibilização do sistema operacional como open source não apenas fortalece essa estratégia, mas também posiciona o país como um potencial definidor de padrões tecnológicos na próxima geração da computação.

Do ponto de vista do desenvolvedor, o impacto pode ser significativo. A existência de um sistema operacional quântico acessível permite experimentar com arquiteturas completas, sem a necessidade de construir toda a camada de integração do zero. Isso pode acelerar o desenvolvimento de aplicações práticas em áreas como criptografia, otimização, simulação de materiais e inteligência artificial quântica. Ao mesmo tempo, cria-se um novo paradigma de desenvolvimento, onde entender o comportamento do hardware e sua interação com o software passa a ser tão importante quanto escrever algoritmos quânticos.

Em síntese, o Origin Pilot não deve ser visto apenas como mais uma ferramenta no ecossistema quântico, mas como um passo em direção à maturidade da computação quântica como plataforma.

Assim como os sistemas operacionais clássicos foram fundamentais para a popularização dos computadores pessoais, iniciativas como essa podem desempenhar papel semelhante no futuro da computação quântica, definindo como os sistemas serão construídos, utilizados e evoluídos nas próximas décadas.

Referências:
https://www.globaltimes.cn/page/202602/1355718.shtml
https://postquantum.com/quantum-computing/china-quantum-os-origin-pilot/
https://medium.com/%40noahbean3396/quantum-computers-need-a-new-kind-of-operating-system-the-first-generation-just-arrived-aeeaa0c9bb60
https://en.chinadiplomacy.org.cn/2026-03/19/content_118390706.shtml

Download: https://qcloud.originqc.com.cn/en/programming/pilotos

A evolução da inferência de IA em hardware Intel continua em ritmo acelerado, e o lançamento do OpenVINO 2026.1 consolida mais um avanço importante nessa jornada. Se a versão 2026.0 já havia estabelecido um novo patamar com suporte a Mixture of Experts (MoE), pipelines de Text-to-Video e técnicas mais inteligentes de compressão, a nova versão vai além: amplia significativamente o suporte a modelos, melhora a eficiência operacional e reforça o posicionamento do OpenVINO como uma das principais plataformas para inferência de IA em ambientes reais.

Mais do que uma atualização incremental, o OpenVINO 2026.1 representa uma resposta direta às demandas atuais do mercado: modelos maiores, workloads multimodais e a necessidade constante de reduzir latência sem comprometer qualidade.

Expansão de Modelos: Escalando a IA com Flexibilidade

Um dos pontos mais relevantes desta versão é a ampliação do suporte a modelos de grande porte e multimodais. O destaque vai para o suporte em CPU ao GPT-OSS 120B, um salto expressivo em relação à versão anterior (20B). Isso muda o jogo para organizações que precisam rodar modelos massivos sem depender exclusivamente de GPUs de alto custo.

Além disso, o suporte ao Qwen3 VL em CPU e GPU abre novas possibilidades para aplicações avançadas de visão computacional combinada com linguagem natural. Estamos falando de casos de uso como:

• Análise inteligente de imagens e vídeos
• Geração automática de descrições visuais
• Processamento documental com entendimento semântico
• Raciocínio multimodal em tempo real

Outro avanço importante está no OpenVINO Model Server, que agora suporta melhor modelos como Qwen3-MoE e GPT-OSS-20B. Com isso, há ganhos diretos em:

• Throughput via continuous batching
• Melhor uso de recursos em ambientes concorrentes
• Maior estabilidade em cenários de produção

E não para por aí: a introdução de endpoints de imagem com suporte a inpainting e outpainting leva o Model Server para além da inferência textual, entrando definitivamente no território da IA generativa visual.

LoRA Dinâmico e IA Multimodal: Eficiência em Escala

A adoção de LoRA dinâmico para modelos de visão e linguagem é um divisor de águas. Com suporte ao Qwen3-VL, o OpenVINO permite trocar adaptadores em tempo de execução sem recarregar o modelo base.

Na prática, isso resolve um problema crítico em produção: como servir múltiplas variações de um modelo sem multiplicar o consumo de memória e tempo de inicialização. O resultado é:

• Menor latência operacional
• Redução de custo de infraestrutura
• Maior flexibilidade para personalização de modelos

Outro ponto extremamente relevante é o novo notebook de referência que integra múltiplos VLMs, incluindo:

• Qwen2.5-VL
• LLaVA-Next-Video

Esse ambiente unificado permite explorar chatbots multimodais com suporte a vídeo e alternância dinâmica de modelos algo essencial para experimentação e benchmarking em cenários reais.

Performance: Onde o OpenVINO Realmente Brilha

Se há um ponto onde o OpenVINO tradicionalmente se destaca, é na otimização de performance e a versão 2026.1 reforça isso com avanços consistentes.

1. TaylorSeer Lite Caching

A introdução do caching TaylorSeer Lite para pipelines de difusão (como Flux, SD3 e LTX-Video) reduz computações redundantes durante o processo de denoising. Isso resulta em:

• Geração mais rápida de imagens e vídeos
• Menor consumo computacional
• Manutenção da qualidade do output

2. Otimizações em Vídeo (LTX-Video)

A fusão de operadores como RMSNorm e RoPE em um único kernel elimina overhead de execução sequencial. Esse tipo de otimização de baixo nível traz ganhos significativos:

• Redução de latência de kernel
• Menor uso de memória
• Aumento expressivo no throughput

3. Prompt Lookup Decoding

A extensão dessa técnica para pipelines multimodais é um dos avanços mais interessantes. Ao reutilizar padrões de tokens já processados, o sistema reduz a carga no modelo principal, acelerando a geração de tokens.

Isso é particularmente relevante para:

• Chatbots multimodais
• Assistentes com contexto longo
• Sistemas de análise documental

Um Novo Patamar para Inferência em Hardware Intel

O OpenVINO 2026.1 deixa claro que a estratégia da Intel não é apenas competir é redefinir o espaço de inferência eficiente. Ao permitir que modelos massivos rodem em CPU, otimizar pipelines multimodais e introduzir mecanismos inteligentes de caching e decoding, a plataforma se posiciona como uma solução altamente pragmática para empresas.

Em um cenário onde custo, performance e escalabilidade precisam coexistir, o OpenVINO oferece uma proposta extremamente equilibrada.

Para quem trabalha com IA aplicada seja em edge, cloud ou ambientes híbridos essa versão não é apenas uma atualização. É um convite para repensar arquitetura, otimizar pipelines e explorar novas possibilidades com modelos cada vez mais complexos.

Conclusão

O OpenVINO 2026.1 representa um avanço sólido na democratização da IA de alto desempenho. Com mais modelos, melhor suporte multimodal e otimizações profundas de performance, a plataforma continua evoluindo para atender às demandas reais do mercado.

Se você está construindo soluções com LLMs, VLMs ou pipelines generativos, este é o momento ideal para explorar o que há de novo e, principalmente, para extrair o máximo desempenho do hardware Intel com inteligência.

A próxima geração da IA não será apenas mais poderosa , será mais eficiente. E o OpenVINO está claramente liderando esse movimento.

O Zupt é uma ferramenta open source de backup que combina compressao de dados com criptografia autenticada e, no modo --pq, proteção pós-quântica baseada em ML-KEM-768 + X25519. No repositório oficial, o projeto é descrito como uma solução em C11 puro, sem dependências externas, voltada para criar arquivos de backup comprimidos e, quando necessário, protegidos com criptografia clássica por senha ou com encapsulamento híbrido resistente ao cenário de computação quântica.

O projeto teve início com a implementação em C desenvolvida por Cristian Cezar Moises.

Como Membro e Embaixador openSUSE e Chapter Lider OWASP SP, entrei na iniciativa para viabilizar sua compilação em conformidade com os requisitos de compliance das distribuições Linux.

Além de atuar no port para as arquiteturas x86, ppc64le, armv7l, aarch64 e s390x. Esta primeira etapa está sendo realizada no openSUSE, permitindo que o DiraQ (um Linux de bolso para Computação Quântica que desenvolvi com Wilson Fonseca ) já incorpore esse recurso, cuja demonstração acontecerá no UNISO Quantum Day dia 7 de Abril.

A ideia central do Zupt é simples: transformar backup em um único fluxo operacional. Em vez de usar uma ferramenta para compactar, outra para cifrar e outra para validar integridade, o Zupt concentra tudo em um só utilitário. O projeto destaca compressão, autenticação por bloco, execução multithread, ocultação de nomes/estrutura dos arquivos dentro do archive e um modo pós-quântico para arquivos que precisam continuar confidenciais por muitos anos.

OK, mas o que significa “pós-quântico” no Zupt

Para entender o diferencial do Zupt, é importante entender o papel do ML-KEM. O NIST define ML-KEM em seu padrão FIPS 203 como um KEM (Key-Encapsulation Mechanism), isto é, um mecanismo de encapsulamento de chave que permite a duas partes estabelecerem um segredo compartilhado por um canal público, para depois usar esse segredo em algoritmos simétricos de criptografia e autenticação. O padrão prevê três conjuntos de parâmetros: ML-KEM-512, ML-KEM-768 e ML-KEM-1024. (Fonte NIST)

No Zupt, o modo --pq usa especificamente o ML-KEM-768, que o próprio SECURITY.md classifica como um esquema de nível de segurança NIST 3, combinado com X25519 em um desenho híbrido. Em outras palavras, o archive não depende só de um algoritmo “novo” pós-quântico, nem só de um algoritmo clássico consagrado: ele deriva a chave de proteção a partir da combinação dos dois. Isso torna o modelo particularmente interessante para migração gradual, porque ele mantém a robustez clássica e adiciona uma camada pensada para a ameaça quântica.

O repositório resume esse benefício com a expressão “harvest now, decrypt later”. Esse risco descreve o cenário em que um adversário intercepta dados cifrados hoje, armazena tudo e espera o futuro, quando a computação quântica ou novos ataques possam quebrar mecanismos clássicos.

O README do Zupt diz explicitamente que o modo --pq existe para enfrentar esse problema; o SECURITY.md reforça que o modo com senha (-p) não é quântico-seguro e recomenda --pq para proteção de longo prazo.

Quando o projeto afirma que essa ideia segue a mesma linha de produtos como Signal e iMessage, a comparação faz sentido no nível conceitual: o Signal documenta seu protocolo PQXDH como uma combinação de X25519 com Kyber/ML-KEM, e a Apple também descreve sua transição para criptografia híbrida pós-quântica no iMessage/PQ3 como resposta ao risco de ataques futuros contra material coletado hoje. O ponto principal não é que Zupt replique literalmente esses protocolos de mensageria, mas que ele adota a mesma filosofia de hibridização entre o mundo clássico e o pós-quântico. (Fonte Signal)

Como o modo --pq funciona na prática

O fluxo híbrido do Zupt funciona assim: a chave pública do destinatário é usada em uma encapsulação ML-KEM-768; ao mesmo tempo, o programa faz uma troca baseada em X25519; depois, os segredos resultantes são combinados e passam por SHA3-512 para derivar duas chaves: uma de cifragem e outra de autenticação. Essas chaves então alimentam o mecanismo simétrico já usado pelo programa, baseado em AES-256-CTR para confidencialidade e HMAC-SHA256 para integridade.

A consequência prática desse desenho é importante: o projeto afirma que o archive continua protegido se pelo menos um dos dois componentes permanecer seguro. Ou seja, mesmo que no futuro surja uma quebra relevante contra X25519, o componente ML-KEM-768 ainda sustentaria a segurança; e, no cenário inverso, o componente clássico ainda adicionaria proteção enquanto permanecesse confiável. Esse é exatamente o valor de um desenho híbrido em uma fase de transição criptográfica.

O que mais o Zupt oferece além do modo pós-quântico

Embora o modo --pq seja o grande diferencial, o Zupt não é “só” um experimento de criptografia. O README destaca compressão, autenticação por bloco, paralelismo e um codec chamado VaptVupt, descrito como o codec padrão da linha 2.0, combinando LZ77 + tANS com aceleração AVX2 para descompressão (Uau).

O projeto também apresenta comparação funcional com gzip, zstd e 7-Zip, ressaltando que o ganho do Zupt não é apenas taxa de compressão, mas a soma de compressão, integridade, criptografia e independência de bibliotecas externas. Também vale uma observação editorial importante para o seu artigo: no momento da consulta, a página do repositório mostrava v1.5.5 como release mais recente publicada, mas o README do branch master já descrevia a linha 2.0-RC e seus recursos, incluindo o VaptVupt como padrão. Para um texto técnico honesto, vale explicitar que parte da documentação do projeto reflete uma transição de versões.

Instalação do Zupt a partir dos fontes no openSUSE

No fluxo de compilação a partir do GitHub, o README oficial documenta um processo direto: clonar o repositório, entrar no diretório, executar make e depois sudo make install. O Makefile confirma que o compilador padrão é gcc, que o binário gerado chama-se zupt e que a instalação, por padrão, vai para /usr/local/bin. Como o procedimento usa git clone, make e gcc, no openSUSE o caminho mais lógico é preparar o ambiente com esses pacotes antes da compilação.

Os pré-requisitos mínimos no openSUSE podem ser instalados assim:

sudo zypper install git gcc make

Em seguida, faça a compilação:

git clone https://github.com/cristiancmoises/zupt.git
cd zupt
make
sudo make install

Depois da instalação, você pode confirmar que o binário entrou corretamente no sistema com:

which zupt
zupt version
zupt help

Esse fluxo está alinhado ao README e ao Makefile do projeto, que mostram build sem dependências externas além do toolchain C padrão.

Instalação do Zupt via zypper no openSUSE

O README também documenta instalação por pacote no ecossistema openSUSE. No trecho consultado, a instrução publicada era adicionar o repositório da iniciativa e instalar o pacote com zypper. Como o texto do repositório explicitava o exemplo para openSUSE 16.0, o mais correto é reproduzir exatamente esse procedimento no artigo, sem extrapolar para versões que não estejam listadas no README consultado.

sudo zypper addrepo https://download.opensuse.org/repositories/home:cabelo:innovators/16.0/home:cabelo:innovators.repo
sudo zypper refresh
sudo zypper install zupt

Após isso, os mesmos comandos de verificação continuam válidos:

zupt version
zupt help

Esse método é o mais prático para quem quer começar rapidamente, enquanto a instalação via fonte é mais interessante para auditoria de código, testes com mudanças locais ou validação de uma branch específica.

Uso básico do Zupt

A interface principal do programa gira em torno de alguns subcomandos: compress, extract, list, test, bench, keygen, version e help. O README mostra o formato geral como zupt compress [OPTIONS] <output.zupt> <files/dirs...> e zupt extract [OPTIONS] <archive.zupt>, além de opções como nível de compressão, número de threads, senha, modo pós-quântico, saída de extração e modos de codec.

1. Criando um backup simples sem criptografia

Para apenas compactar arquivos, o uso básico documentado é:

zupt compress backup.zupt ~/Documents/

Esse comando cria um archive .zupt usando o codec padrão documentado no branch atual do projeto. É o modo indicado para dados não sensíveis ou para testes rápidos de desempenho e formato.

2. Criando um backup com senha

Se a intenção é proteger o conteúdo com senha, o README mostra:

zupt compress -p "changeme" backup.zupt ~/Documents/

Nesse caso, o SECURITY.md diz que a derivação passa por PBKDF2-SHA256 e gera chaves para AES-256-CTR + HMAC-SHA256. É uma proteção útil para uso comum, mas a própria documentação alerta que esse modo não é o indicado para proteção de longo prazo contra ameaça quântica.

3. Extraindo um backup

Para restaurar o conteúdo em um diretório específico, o fluxo documentado é:

zupt extract -o ~/restored/ backup.zupt

Se o archive tiver sido protegido com senha, a senha deve ser informada no comando; se tiver sido criado com --pq, será preciso usar a chave privada correspondente. A opção -o define o diretório de destino da restauração.

4. Criando um backup pós-quântico

O modo pós-quântico documentado no README envolve primeiro gerar um par de chaves, depois exportar a chave pública e usá-la na compressão:

zupt keygen -o mykey.key
zupt keygen --pub -o pub.key -k mykey.key
zupt compress --pq pub.key backup.zupt ~/Documents/

Para extrair depois:

zupt extract --pq mykey.key -o ~/restored/ backup.zupt

A lógica é semelhante a fluxos de criptografia de chave pública: quem cria o backup usa a chave pública para proteger o archive, e só quem possui a chave privada consegue abrir o conteúdo. Para arquivos arquivísticos, backups frios, documentos estratégicos e material com exigência de sigilo prolongado, este é o modo mais interessante do Zupt.

5. Listando, testando e ajustando o comportamento

Além de comprimir e extrair, o README informa que o Zupt também oferece:

zupt list backup.zupt
zupt test backup.zupt

list serve para inspecionar o archive, e test para validar integridade. O projeto também documenta -l <1-9> para nível de compressão, -t <N> para número de threads, -s para armazenar sem compressão, -f para codec rápido legado e --solid para modo sólido. Isso permite adaptar o comportamento entre velocidade, taxa de compressão e custo de CPU.

Cuidados e limitações que merecem atenção

Um artigo técnico sobre o Zupt fica mais forte quando menciona não apenas os recursos, mas também os limites atuais. O COMPAT.md informa, por exemplo, que links simbólicos são ignorados, arquivos especiais também podem ser ignorados, e as permissões dos arquivos ainda não são restauradas na extração; o documento também cita limites para tamanho de bloco, quantidade de arquivos e algumas restrições de modo sólido.

Além disso, o README do branch atual é explícito ao dizer que a linha 2.0-RC já está adequada para uso pessoal e testes, mas ainda não é indicada para ambientes críticos ou grandes volumes de dados. Portanto, um texto responsável deve apresentar o Zupt como uma ferramenta muito promissora, tecnicamente interessante e especialmente relevante por trazer criptografia híbrida pós-quântica ao universo de backup, mas ainda em evolução.

Conclusão

O Zupt se destaca por atacar um problema real com uma abordagem moderna: backup não é só compactar arquivos, é preservar confidencialidade, integridade e recuperabilidade por muitos anos. Ao combinar compressão, autenticação por bloco, execução paralela e um modo híbrido ML-KEM-768 + X25519, a ferramenta entra em um espaço ainda pouco explorado por utilitários de backup open source. O grande valor do projeto está justamente em aproximar a discussão de criptografia pós-quântica da operação cotidiana de backup.

No dia 31 de março de 2026, um evento chamou a atenção da comunidade de engenharia de software e segurança: o suposto vazamento completo do código-fonte do Claude Code, CLI oficial da Anthropic.

Mas o mais curioso?
Não foi um ataque sofisticado.

Foi algo muito mais comum e perigoso: um source map publicado no npm.

O que aconteceu

Um pesquisador de segurança identificou que o pacote @anthropic-ai/claude-code incluía um arquivo .map de aproximadamente 57 MB, contendo o código original completo da aplicação. Esse tipo de arquivo é usado normalmente para debug, mapeando código minificado de volta ao original mas, neste caso, ele continha todo o código em texto puro dentro da propriedade sourcesContent.

O resultado:

• ~1.900 arquivos
• 512.000+ linhas de código TypeScript
• Arquitetura completa de produção exposta

Ou seja: não foi um
leak parcial.
Foi o sistema inteiro.

O que existe dentro do Claude Code

O vazamento revelou algo muito mais interessante do que apenas código revelou como uma IA moderna de desenvolvimento realmente funciona por dentro.

Arquitetura real (não marketing)

O Claude Code não é apenas um wrapper de chat. Ele é um sistema complexo com:

• Sistema de ferramentas (tool-based)
  Cada ação (ler arquivo, executar bash, buscar web) é um módulo isolado e com permissões.
• Query Engine (~46k linhas)
  Responsável por orquestrar chamadas ao modelo, cache, streaming e controle de execução.
• Multi-agentes (“swarms”)
  Capacidade de criar agentes paralelos para resolver tarefas complexas.
• Integração com IDEs
  Comunicação com VS Code e JetBrains via canais autenticados.

Tudo isso rodando sobre Bun + React (Ink) no terminal.

O que mais chamou atenção (e preocupa)

Esse tipo de vazamento não expõe só código ele expõe modelo mental e decisões de segurança.

Entre os pontos críticos identificados:

• System prompts e lógica interna de comportamento
• Modelo de permissões de ferramentas
• Proteções contra path traversal e acesso indevido
• Features beta não lançadas
• Estratégias de orquestração de agentes

Além disso, foram encontrados codenames internos como:

• KAIROS → modo persistente “always-on”
• Capybara → outro subsistema interno
• Flags de recursos como:
  • contexto de 1 milhão de tokens
  • “interleaved thinking”
  • controle de esforço e modo rápido

A falha real: supply chain e build pipeline

O mais importante aqui não é o Claude. É o padrão. Esse incidente reforça um problema recorrente:

Falhas em pipelines de build e publicação são hoje uma das maiores superfícies de ataque.

O erro foi simples:

• O bundler gerou .map
• O .npmignore não excluiu
• Nenhum pre-check validou o pacote antes do publish

Resultado: qualquer pessoa com npm pack tinha acesso ao código inteiro.

Insight estratégico (o que isso nos ensina)

Esse caso revela três coisas fundamentais sobre o futuro da IA:

1. IA moderna = sistemas complexos, não modelos isolados

O diferencial não está só no LLM está na orquestração.

2. Segurança de IA não é só prompt injection

É:

• supply chain
• permissões de ferramentas
• controle de execução

3. Transparência involuntária acelera aprendizado global

Mesmo sendo um incidente, ele oferece um “raio-x” de como sistemas state-of-the-art são construídos.

Conexão com o futuro (e com o que estamos construindo)

Se você trabalha com:

• sistemas multi-agente
• execução local/offline de IA
• orquestração de ferramentas

Esse vazamento praticamente confirma uma direção:

O futuro da IA está na integração entre modelo + sistema operacional + runtime de execução.

Algo muito próximo do que já vemos emergindo em iniciativas como:

• AI-native OS
• agentes autônomos
• computação heterogênea (CPU + GPU + NPU)

Conclusão

Não foi apenas um vazamento. Foi um lembrete.Onde:

• segurança básica ainda falha
• sistemas de IA são mais complexos do que parecem
• e estamos apenas começando a entender como esses sistemas realmente funcionam

E talvez o ponto mais importante:

Quem dominar a arquitetura, não só o modelo vai dominar a próxima geração da IA.

Nos últimos dias, muito se discutiu muitas vezes com desinformação sobre a aplicação de conceitos do chamado “ECA Digital” (ou apelidado de “Lei Felca”) no ecossistema Linux. A narrativa dominante sugere restrições, controle excessivo ou até inviabilidade do uso de sistemas abertos.

E esse problema já tem solução.

É possível implementar mecanismos de proteção infantil diretamente no sistema operacional Linux, de forma 100% offline, sem coleta de dados e sem dependência de cloud, utilizando o estado da arte em Inteligência Artificial: VLMs (Vision-Language Models), redes neurais convolucionais (CNNs) e agentes inteligentes.

O Problema: Controle de Acesso por Idade no Linux

Ambientes Linux tradicionalmente utilizam autenticação baseada em senha, chave ou biometria simples. Porém, nenhum desses mecanismos responde a uma pergunta essencial no contexto do ECA Digital:

Quem está tentando obter privilégios administrativos é realmente um adulto autorizado?

Isso abre espaço para cenários comuns:

• Crianças tentando instalar software inadequado
• Uso indevido de credenciais dos pais
• Escalada de privilégio sem contexto de idade

A Solução: VLM + CNN com Agentes Inteligentes

A arquitetura proposta combina três componentes principais:

1. VLM (Vision-Language Model)

O VLM atua como camada semântica, interpretando a cena capturada pela câmera:

• Contexto do usuário diante do dispositivo
• Interação com prompts de validação
• Auxílio na inferência de idade com base visual

2. CNN (Redes Neurais Convolucionais)

As CNNs são responsáveis pela parte crítica:

• Detecção facial em tempo real
• Estimativa de idade (age estimation)
• Classificação etária (criança vs adulto)

Esse modelo é otimizado para execução local (edge), sem necessidade de GPU de alto custo.

3. Agentes de Decisão

Agentes inteligentes orquestram o fluxo:

• Validam se a ação requer privilégio root
• Disparam a análise visual
• Decidem permitir ou bloquear a operação

Teste de Vivacidade (Liveness Detection)

Um dos pontos mais importantes do sistema é evitar fraudes. Não basta detectar um rosto é necessário garantir que ele é real. O sistema impede ataques usando foto impressas e Vídeos doa pais.

Privacidade por Design: 100% Offline

Diferente de soluções comerciais, este modelo segue um princípio fundamental:

Nenhum dado é armazenado. Nenhuma imagem sai da máquina.

Características:

• Processamento local (edge computing)
• Sem envio para APIs externas
• Sem armazenamento de imagens ou embeddings
• Apenas decisão binária em tempo real (permitir/bloquear)

Isso elimina riscos de:

• Vazamento de dados
• Compliance com LGPD
• Dependência de serviços cloud

Integração Profunda com Linux via PAM

Toda essa inteligência não roda como um aplicativo isolado. Ela foi integrada diretamente ao sistema de autenticação do Linux através do PAM (Pluggable Authentication Modules).

Como funciona na prática:

1. Usuário executa um comando com sudo ou tenta acesso root
2. O PAM intercepta a requisição
3. O módulo customizado ativa o pipeline de IA
4. A câmera captura o rosto do usuário
5. O modelo CNN + VLM analisa idade e vivacidade
6. O agente decide:
   • ✅ Adulto → libera autenticação
   • ❌ Criança → bloqueia operação

Tudo isso acontece antes da concessão de privilégios.

Vantagens dessa abordagem:

• Transparente para o usuário
• Integrado ao sistema operacional
• Funciona com qualquer aplicação que use PAM (sudo, login, ssh, etc.)
• Baixo impacto de performance

Impacto no Mercado: Linux Compatível com ECA Digital

Essa abordagem resolve diretamente o principal argumento usado contra o Linux em ambientes regulados:

“Linux não tem controle de acesso por idade”

Agora tem e de forma mais avançada que qualquer sistema tradicional.

Benefícios:

• Adequação ao conceito de ECA Digital
• Controle parental real, não apenas superficial
• Segurança sem invasão de privacidade
• Total soberania de dados (zero cloud)

Conclusão

O debate sobre restrições ao Linux baseado em desinformação ignora o avanço tecnológico disponível hoje.

Combinando:

• VLM
• CNN
• Agentes inteligentes
• Integração via PAM

é possível criar um sistema de controle de privilégios inteligente, privado e totalmente offline.

Isso não apenas resolve as preocupações do mercado como posiciona o Linux à frente, oferecendo uma solução mais segura, auditável e alinhada com princípios modernos de privacidade. Vejam o sistema funcionando abaixo:

A repercussão em torno da Lei 15.211/2025 mostrou, mais uma vez, como informação sem fundamento pode ser transformada em histeria coletiva quando quase ninguém se dá ao trabalho de ler o texto original da norma. No lugar da leitura, entrou o impulso por curtidas, engajamento e manchetes apocalípticas. O resultado foi previsível: uma onda de desinformação sobre uma suposta “proibição do Linux no Brasil”.

Nos últimos dias, recebi diversos e-mails e mensagens de pessoas preocupadas com a ideia de que a chamada “Lei Felca” abriria caminho para banir distribuições Linux no país. A narrativa se espalhou com velocidade impressionante, impulsionada principalmente por gente que jamais instalou, administrou ou sequer utilizou GNU/Linux de forma real no dia a dia, mas que se sentiu confortável para decretar o seu “fim” nas redes sociais.

O episódio ganhou ainda mais ruído em 17 de março, quando a distribuição Arch Linux 32 bloqueou o acesso a partir do Brasil. Para quem não conhece, trata-se de um projeto comunitário independente, um fork do Arch Linux tradicional, mantido para oferecer suporte a máquinas antigas com arquitetura de 32 bits (i686). A decisão desse projeto específico foi rapidamente tratada por muita gente como se fosse prova definitiva de que “o Linux havia sido bloqueado no Brasil”, o que evidentemente não corresponde aos fatos.

Falo disso com a tranquilidade de quem leva Linux a sério desde 1998, contribui com projetos open source e participa de palestras e iniciativas voltadas à comunidade. Para mim, usar Linux não é modismo, discurso de rede social ou bandeira ideológica de ocasião. É prática, trabalho árduo e convicção. Por isso, antes de repetir boatos, fui fazer o que quase ninguém fez: Buscar minimamente informações sobre a lei (Paulo Henrique Alkmin fez este trabalho o que facilitou este post).

A Lei nº 15.211, sancionada em setembro de 2025 e vigente a partir de 17 de março de 2026, institui o chamado Estatuto Digital da Criança e do Adolescente. O apelido “Lei Felca” surgiu em referência ao youtuber cujo vídeo sobre exploração infantil em redes sociais acelerou a tramitação do tema no Congresso. Até aí, tudo bem. O problema começou quando parte do debate público resolveu transformar uma leitura superficial em profecia técnica.

De fato, o Art. 1º estabelece que a lei se aplica a produtos e serviços de tecnologia da informação direcionados a crianças e adolescentes no país, ou com provável acesso por eles. Já o Art. 2º, inciso I, menciona exemplos como aplicações de internet, programas de computador, softwares, sistemas operacionais de terminais, lojas de aplicativos e jogos eletrônicos. Foi justamente a presença da expressão “sistemas operacionais” que bastou para disparar o pânico.

Mas o mais curioso é que a própria lei contém dispositivos que enfraquecem frontalmente a tese de que haveria espaço para uma proibição ampla de Linux ou qualquer outro sistema operacional (Obrigado novamente Paulo Henrique Alkmin ).

O primeiro ponto ignorado por quase todo mundo está no Art. 2º, § 2º, que exclui do escopo da lei as funcionalidades essenciais ao funcionamento da internet, incluindo protocolos e padrões técnicos abertos e comuns. Basta lembrar que o kernel Linux está presente em mais de 96% dos servidores web do mundo para perceber o tamanho do absurdo da narrativa criada. Estamos falando de uma base tecnológica central da infraestrutura global da internet, não de um aplicativo qualquer.

O segundo ponto relevante aparece no Art. 14, parágrafo único. Ali, a lei deixa claro que, independentemente das medidas adotadas por sistemas operacionais e lojas de aplicativos, os fornecedores das próprias aplicações devem implementar mecanismos para impedir o acesso indevido. Em outras palavras: a responsabilidade principal recai sobre a aplicação, não sobre o sistema operacional. Se uma rede social precisa adotar verificação etária, o dever primário é da plataforma. O sistema operacional pode até ter um papel complementar, mas não é o centro da obrigação.

O terceiro ponto, talvez o mais ignorado de todos, está no Art. 37, parágrafo único, que veda regulamentações que resultem em mecanismos de vigilância massiva, genérica ou indiscriminada, além de resguardar explicitamente direitos como liberdade de expressão e privacidade. Bloquear o uso de um sistema operacional inteiro como resposta regulatória seria, justamente, uma medida genérica, indiscriminada e incompatível com esse espírito.

Ou seja: bastariam três trechos da própria lei para desmontar a história do “Linux proibido”. Três dispositivos. No mesmo texto legal. Ainda assim, muita gente preferiu ignorá-los para manter viva a narrativa do caos.

A desinformação se espalhou em dois eixos ao mesmo tempo. De um lado, houve exploração política. De outro, houve um ruído técnico lamentável, inclusive entre pessoas da própria comunidade de tecnologia, que transformaram um “pode impactar discussões futuras” em “vai proibir o Linux”. É sempre mais fácil viralizar com uma frase catastrófica do que ler e interpretar os 37 artigos de uma lei.

Outro argumento que apareceu com frequência foi o de que o GNU/Linux “não teria mecanismos de controle parental” ou que seria incapaz de se adaptar a exigências legais voltadas à proteção de menores. Isso também revela desconhecimento técnico. O ecossistema Linux já dispõe de soluções concretas para esse tipo de necessidade. Há ferramentas como Malcontent, além de repositórios que exigem classificação etária de aplicativos com base no padrão OARS (Open Age Ratings Service). Também existem soluções como o Timekpr-nExT, que permite estabelecer limites diários, semanais e mensais de uso, e o CTparental, que oferece gestão de tempo e controle de conteúdo acessado ou baixado na internet.

Ou seja, além de a tese do “banimento” não se sustentar juridicamente, ela também fracassa tecnicamente. O GNU/Linux não é um ambiente sem recursos, sem governança ou sem capacidade de adaptação. Pelo contrário: justamente por ser aberto, auditável e colaborativo, ele frequentemente consegue responder com mais agilidade e transparência a desafios técnicos do que plataformas fechadas.

E digo mais: Se em algum momento surgisse uma exigência real para integração de verificação etária ou mecanismos complementares dentro do sistema operacional, a própria comunidade open source teria plena capacidade de responder.

Eu mesmo sozinho iria procurar a Serpro ou Gov.BR e implementaria integração com APIs com base de fé pública “e/ou privada” em módulos PAM, se necessário fosse. (exemplo vídeo abaixo). Agora imagine o que aconteceria se toda a comunidade resolvesse atacar o problema de forma coordenada. A chance do resultado ser tecnicamente melhor comparado as plataformas proprietárias seria enorme.

No fim, esse episódio não fala apenas sobre Linux ou sobre a Lei 15.211/2025. Ele revela algo mais amplo e preocupante: a velocidade com que boatos se tornam “verdades” quando são emocionalmente convenientes. Em vez de leitura, contexto e análise, escolhe-se o pânico performático. Em vez de debate sério, produz-se barulho.

A lição é simples. Antes de decretar o fim do Linux, do software livre ou da internet como conhecemos, vale a pena fazer o básico: ler a lei. Porque, neste caso, o suposto escândalo nasceu muito menos do texto legal e muito mais da preguiça intelectual de quem preferiu acreditar na desinformação.

Use a FORÇA, Leia os fontes
e USE LINUX!