- Área de tecnologia principal: Azure | Microsoft Azure
- Áreas de tecnologia adicionais: IA
- Dados do autor: https://linktr.ee/edupopov
Uma reflexão sobre o impacto da Inteligência Artificial na computação em nuvem, na cibersegurança e no futuro dos profissionais de tecnologia.
Criar uma solução realmente funcional utilizando Inteligência Artificial, especialmente modelos locais como o BitNet, não é uma tarefa tão simples quanto parece. Embora estejamos vivendo um período em que praticamente qualquer pessoa consegue interagir com uma IA generativa, existe uma diferença considerável entre solicitar a criação de algo e compreender tecnicamente aquilo que está sendo construído.
E aqui chegamos a um ponto que considero particularmente interessante: a Inteligência Artificial está transformando profundamente o papel dos profissionais de tecnologia, mas talvez não da maneira como muitos imaginam.
Sejamos francos. Analistas de infraestrutura, desenvolvedores, administradores de sistemas e arquitetos de Cloud que trabalham apenas reproduzindo procedimentos, sem compreender os fundamentos das tecnologias que utilizam, provavelmente enfrentarão dificuldades cada vez maiores para justificar seu papel no mercado.
Não estou afirmando que essas profissões desaparecerão. Pelo contrário. Acredito que profissionais verdadeiramente qualificados se tornarão ainda mais importantes. Entretanto, aqueles que estão apenas turistando pela tecnologia, executando tarefas mecanicamente e sem aprofundamento técnico, encontrarão um cenário bastante desafiador.
Afinal, quando uma ferramenta consegue gerar scripts, desenvolver aplicações, propor arquiteturas de nuvem, configurar serviços e identificar problemas em poucos minutos, qual passa a ser o diferencial do profissional que anteriormente dedicava dias a essas mesmas atividades?
Na minha opinião, a resposta está no conhecimento.
A IA pode construir uma infraestrutura, mas ainda precisamos de alguém que compreenda se aquela infraestrutura deveria ter sido construída daquela maneira.
E essa diferença é gigantesca.
Da infraestrutura tradicional à infraestrutura construída com IA
Vou propor um exercício.
Você já experimentou utilizar o GitHub Copilot, integrado ao seu ambiente de desenvolvimento e às ferramentas apropriadas de administração do Azure, para solicitar a construção de uma arquitetura completa de aplicação web?
Imagine o seguinte cenário: sua empresa precisa disponibilizar um frontend corporativo no Microsoft Azure, com alta disponibilidade, balanceamento de carga, redundância entre duas Zonas de Disponibilidade, monitoramento, políticas de segurança e um processo automatizado de implantação.
Em um modelo tradicional, essa atividade envolveria diversas etapas de planejamento e execução. Seria necessário selecionar os serviços, definir a topologia da rede, preparar a infraestrutura, configurar os recursos de segurança, estabelecer a estratégia de distribuição de tráfego, implementar o monitoramento e testar o comportamento da aplicação diante de possíveis falhas.
Dependendo da complexidade do projeto, esse trabalho poderia consumir vários dias.
Agora imagine descrever os requisitos a um assistente de IA com contexto técnico suficiente:
Desenvolva uma arquitetura para disponibilizar uma aplicação frontend no Microsoft Azure, utilizando duas Zonas de Disponibilidade, balanceamento de carga, políticas de segurança, monitoramento centralizado e implantação automatizada. Gere a infraestrutura como código, documente as dependências e apresente uma estimativa de custos operacionais.
A IA poderá propor a arquitetura, gerar templates Bicep ou Terraform, estruturar scripts, preparar pipelines e produzir documentação inicial.
Com integrações e permissões adequadas, agentes especializados também podem participar das etapas de validação e implantação. A própria Microsoft disponibiliza orientações para utilizar GitHub Copilot na geração de Bicep, comandos de Azure CLI e pipelines de infraestrutura.
Uma atividade que anteriormente exigiria vários dias de trabalho pode, em determinados cenários, ter grande parte de sua implementação inicial concluída em horas ou até minutos.
E aqui existe um detalhe fundamental: gerar rapidamente uma arquitetura não significa que ela esteja pronta para produção.
O profissional ainda precisa validar as permissões, os custos, a disponibilidade regional dos serviços, a resiliência, as políticas de segurança e os requisitos de continuidade de negócio.
A IA acelera a construção. O conhecimento técnico determina a qualidade do resultado.
E o Google Cloud Platform? A lógica é semelhante
O mesmo conceito pode ser aplicado ao Google Cloud Platform (GCP).
Imagine solicitar a criação de uma aplicação web conteinerizada utilizando Cloud Run, com imagens armazenadas no Artifact Registry, controle de acesso por IAM, registros centralizados no Cloud Logging e implantação automatizada por Terraform.
Podemos avançar ainda mais e solicitar uma arquitetura multirregional, com balanceamento global, integração com banco de dados, gerenciamento de segredos e escalabilidade orientada à demanda.
Nesse cenário, uma IA pode auxiliar desde o desenho inicial até a geração dos arquivos de infraestrutura como código.
O Google Cloud também disponibiliza projetos e arquiteturas de referência baseados em Terraform, demonstrando como a infraestrutura pode ser definida de maneira declarativa, reutilizável e alinhada às práticas de segurança.
Observe que não estamos falando simplesmente de pedir para uma IA criar uma máquina virtual.
Estamos falando de transformar uma necessidade de negócio em uma arquitetura técnica, descrevendo requisitos e utilizando modelos generativos para acelerar a implementação.
Naturalmente, isso exige conhecimento para identificar quando utilizar Cloud Run em vez de GKE, quando adotar um balanceador global, como distribuir serviços geograficamente e como estabelecer políticas adequadas de identidade e acesso.
É justamente nesse ponto que o profissional experiente continua fazendo a diferença.
BitNet: quando a Inteligência Artificial deixa de depender exclusivamente dos grandes datacenters
Toda essa evolução me levou a outra reflexão: será que realmente precisamos recorrer a grandes modelos hospedados em datacenters para executar qualquer tarefa que envolva Inteligência Artificial?
Foi a partir dessa pergunta que comecei a explorar o BitNet.
Para quem ainda não conhece, BitNet é uma família de arquiteturas de modelos de linguagem desenvolvida com foco em eficiência computacional, utilizando representações numéricas extremamente compactas para seus parâmetros.
Uma de suas variantes mais conhecidas, o BitNet b1.58, utiliza pesos ternários, representados pelos valores -1, 0 e 1. Isso permite uma representação teórica de aproximadamente 1,58 bit por peso, diferentemente dos formatos de maior precisão tradicionalmente empregados em modelos de linguagem.
Na prática, essa abordagem procura reduzir o consumo de memória, a movimentação de dados e o custo computacional das operações de inferência.
A Microsoft também desenvolveu o projeto aberto bitnet.cpp, um mecanismo otimizado para executar modelos compatíveis em processadores convencionais e, em determinadas configurações, GPUs.
O modelo oficial BitNet-b1.58-2B-4T possui aproximadamente 2,4 bilhões de parâmetros e foi treinado com 4 trilhões de tokens. Resultados publicados pela Microsoft demonstram ganhos expressivos de eficiência em cenários específicos de avaliação, embora os resultados reais dependam do hardware, do modelo e da carga de trabalho.
Isso abre possibilidades interessantes.
Estamos falando de executar modelos de linguagem localmente, sem que cada solicitação precise obrigatoriamente ser encaminhada para um serviço externo.
Um notebook, uma estação de trabalho ou um servidor local pode funcionar como ambiente de inferência, atendendo a aplicações específicas, inclusive em redes com acesso restrito à internet.
É importante esclarecer que o BitNet não oferece automaticamente a mesma capacidade de raciocínio ou geração de código de modelos muito maiores. Entretanto, quando combinado com uma base de conhecimento bem estruturada e ferramentas especializadas, pode atender a diversas necessidades práticas com uma infraestrutura significativamente mais modesta.
E foi justamente essa possibilidade que despertou meu interesse.
Minha experiência: construindo um assistente local de cibersegurança
Resolvi transformar essa curiosidade em um experimento prático.
A ideia inicial era relativamente simples: construir um assistente local para apoiar atividades básicas de Pentest, consultas técnicas e análises de infraestrutura.
Não estava interessado em desenvolver um concorrente para os grandes modelos comerciais. Meu objetivo era compreender até onde conseguiria chegar utilizando uma arquitetura leve, processamento local, um consumo computacional reduzido e uma base de conhecimento direcionada.
E, para minha surpresa, os resultados começaram a aparecer.
De maneira bastante humilde, admito que a solução ainda possui limitações. Existem problemas de interpretação, respostas que precisam de refinamento e situações nas quais um modelo maior certamente apresentaria resultados superiores.
Ainda assim, o experimento demonstrou algo importante: um modelo relativamente pequeno pode se tornar bastante útil quando recebe contexto adequado e consegue consultar ferramentas e informações especializadas.
Em vez de depender exclusivamente do conhecimento adquirido durante o treinamento do modelo, comecei a estruturar mecanismos para fornecer informações diretamente relacionadas às atividades que desejava executar.
Foi nesse momento que entrei no universo das RAGs.
O que é uma RAG e por que ela muda o comportamento de uma IA?
RAG é a sigla para Retrieval-Augmented Generation, ou Geração Aumentada por Recuperação.
Trata-se de uma abordagem que combina um modelo generativo com um mecanismo de recuperação de informações externas.
Em termos mais simples, em vez de esperar que a IA tenha todas as respostas armazenadas em seus parâmetros, podemos permitir que ela consulte documentos, bases de dados e outras fontes de conhecimento antes de responder a uma pergunta.
Imagine que você tenha centenas de livros, manuais técnicos, documentações, procedimentos operacionais e artigos sobre cibersegurança.
Seria pouco eficiente tentar retreinar um modelo de linguagem toda vez que um novo documento fosse adicionado à biblioteca.
Com uma arquitetura RAG, podemos extrair e organizar o conteúdo dos documentos, dividir textos extensos em trechos menores, criar índices de pesquisa e recuperar as informações mais relevantes para cada consulta.
Essas informações são então enviadas ao modelo como contexto para a elaboração da resposta.
A Microsoft descreve essa abordagem como uma forma de fundamentar respostas em informações específicas, inclusive dados privados e conteúdos que mudam com frequência.
O fluxo básico pode ser representado assim:
É importante observar que uma RAG não é simplesmente um arquivo PDF convertido em conhecimento permanente do modelo. O documento precisa ser processado, indexado e recuperado quando necessário. O desempenho depende diretamente da qualidade dessas etapas.
Outro aspecto interessante é que a recuperação não precisa ocorrer exclusivamente por pesquisa vetorial. Podemos combinar busca semântica, palavras-chave, filtros por metadados e consultas estruturadas em bancos de dados.
Para minhas necessidades, essa possibilidade abriu um leque considerável de aplicações.
Transformando minha biblioteca técnica em conhecimento consultável
Tenho um acervo bastante rico de livros e materiais técnicos em PDF, especialmente relacionados à cibersegurança, infraestrutura, sistemas operacionais e administração de ambientes corporativos.
Minha primeira ideia foi transformar esse material em uma base de conhecimento local, organizada por assuntos e disponível para consulta por meio de linguagem natural.
O objetivo não era simplesmente perguntar a uma IA qual é a finalidade de um determinado protocolo.
Eu queria ir além.
Imagine fazer perguntas como:
Quais técnicas de reconhecimento de rede estão documentadas na minha biblioteca?
Como interpretar o resultado de uma descoberta de serviços utilizando Nmap?
Quais são as principais diferenças entre determinadas configurações de segurança do Windows Server?
Quais recomendações documentadas podem ajudar a analisar uma configuração incorreta do Active Directory?
Que procedimentos de diagnóstico estão disponíveis para investigar problemas de conectividade entre servidores?
Uma base RAG bem estruturada permite recuperar referências específicas e fornecer contexto ao modelo para responder a essas perguntas.
Também comecei a explorar a integração com ferramentas locais de análise de redes e segurança, sempre pensando em ambientes próprios ou nos quais exista autorização para a realização dos testes.
Nesse tipo de arquitetura, o modelo não precisa necessariamente conhecer todos os parâmetros de cada ferramenta. Ele pode interpretar a solicitação, identificar a operação necessária e encaminhar a execução para um componente especializado.
Existe, portanto, uma diferença entre utilizar um modelo de linguagem para responder perguntas e desenvolver um agente capaz de realizar tarefas.
O modelo interpreta a intenção. A RAG fornece conhecimento. As ferramentas executam operações. A aplicação controla o fluxo.
Essa combinação, mesmo em um ambiente relativamente modesto, pode produzir resultados surpreendentes.
O ponto mais intrigante: quem define as regras de uma IA local?
Durante meus experimentos, um aspecto chamou particularmente minha atenção.
Ao executar um modelo local, percebi que não estava necessariamente submetido aos mesmos mecanismos de moderação, limites de utilização e políticas operacionais impostos por plataformas comerciais de IA.
Isso não significa que uma IA local seja automaticamente livre de qualquer limitação. O próprio modelo pode apresentar comportamentos de recusa decorrentes de seu treinamento, e a aplicação pode implementar mecanismos de controle adicionais.
Entretanto, existe uma diferença importante: em uma arquitetura local, o responsável pela solução possui muito mais autonomia para determinar como o sistema será configurado, quais informações serão utilizadas e quais operações estarão disponíveis.
E essa autonomia me fez lembrar de uma cena do filme Matrix Revolutions.
Existe um momento em que Neo se encontra preso na estação de trem Mobil Ave, um ambiente situado entre dois mundos e controlado pelo programa conhecido como Homem do Trem.
Naquele espaço, as regras convencionais não funcionam exatamente como em outros ambientes da Matrix. O controle pertence a quem administra aquele sistema.
Naturalmente, trata-se de uma analogia, mas considero que ela representa uma reflexão interessante sobre a Inteligência Artificial local.
Quando executamos um modelo em nossa própria infraestrutura, podemos definir políticas de acesso, limites de execução, fontes de conhecimento, integrações e mecanismos de segurança sem depender necessariamente das configurações de uma plataforma externa.
Isso proporciona autonomia, mas também transfere responsabilidade.
Um agente capaz de executar comandos, consultar sistemas ou interagir com ferramentas administrativas precisa de controles adequados. Sem mecanismos de autorização, isolamento e auditoria, erros de interpretação ou instruções maliciosas presentes em documentos podem produzir consequências reais.
Portanto, a ausência de filtros externos não deve ser confundida com uma vantagem absoluta.
A liberdade de controlar uma IA local exige maturidade técnica para estabelecer seus próprios limites.
Essa é uma discussão que, na minha opinião, merece muito mais atenção.
Será que precisamos de grandes modelos para tudo?
Depois de explorar modelos locais, bases RAG e integrações com ferramentas, comecei a questionar a necessidade de recorrer a grandes modelos comerciais para todas as atividades.
Precisamos realmente utilizar um modelo de enorme capacidade computacional para consultar um procedimento interno de suporte?
É necessário consumir tokens em uma API externa para localizar informações em uma documentação SQL?
Faz sentido enviar dados operacionais para um serviço remoto apenas para descobrir quantos equipamentos utilizam determinada versão do Windows?
Talvez não.
Imagine um ambiente corporativo que possua uma base de inventário alimentada por Microsoft Configuration Manager, Active Directory e ferramentas de segurança de endpoint.
Uma IA local poderia interpretar perguntas em linguagem natural, consultar os dados disponíveis e apresentar respostas consolidadas.
Por exemplo:
"Quantos equipamentos com Windows 11 estão registrados no inventário mais recente?"
"Quais máquinas não possuem informações de TPM?"
"Existe alguma diferença entre o inventário do Active Directory e o inventário do SCCM?"
"Quais alterações ocorreram no parque de equipamentos nos últimos três meses?"
Nesse cenário, não precisamos necessariamente de um modelo gigantesco.
Precisamos de uma boa estrutura de dados, consultas confiáveis, mecanismos de interpretação e regras claras sobre quais informações podem ser acessadas.
Aliás, em determinadas situações, uma consulta SQL tradicional continua sendo a melhor maneira de obter um resultado exato. O papel da IA pode ser simplesmente interpretar a pergunta e acionar a consulta correta, sem inventar números ou tentar realizar cálculos sobre grandes volumes de texto.
Esse é um exemplo de aplicação na qual o conhecimento de arquitetura, bancos de dados e engenharia de software se torna tão importante quanto o próprio modelo de linguagem.
IA local versus IA em nuvem: não se trata de escolher um vencedor
Não acredito que modelos locais substituirão completamente as grandes plataformas de Inteligência Artificial.
Também não acredito que seja racional utilizar serviços de alta capacidade computacional para resolver indiscriminadamente qualquer problema.
Os dois modelos possuem características diferentes.
Característica | IA local | IA em nuvem |
|---|---|---|
Processamento | Hardware próprio | Infraestrutura do provedor |
Custos | Equipamentos, energia e manutenção | Consumo, assinaturas e serviços |
Privacidade | Dados podem permanecer no ambiente local | Depende do serviço e das configurações |
Capacidade | Limitada pelo modelo e hardware disponíveis | Acesso a modelos geralmente mais poderosos |
Disponibilidade offline | Possível | Normalmente depende de conectividade |
Escalabilidade | Exige planejamento de capacidade própria | Pode utilizar serviços gerenciados e escaláveis |
Administração | Responsabilidade da equipe local | Responsabilidade compartilhada com o provedor |
O que considero particularmente promissor é a possibilidade de construir arquiteturas híbridas.
Podemos utilizar um modelo local para interpretar perguntas simples, pesquisar documentos e consultar informações internas, recorrendo a modelos maiores somente quando a complexidade da tarefa justificar.
Essa abordagem exige mecanismos de classificação de solicitações, controle de contexto e encaminhamento inteligente, mas pode oferecer um equilíbrio interessante entre custos, privacidade e capacidade computacional.
Também precisamos considerar que executar um modelo local não significa eliminar custos. Existe investimento em hardware, armazenamento, energia elétrica, manutenção e desenvolvimento da aplicação.
A economia precisa ser avaliada a partir da carga de trabalho real, não apenas da ausência de cobrança por tokens.
O futuro não pertence a quem apenas sabe escrever prompts
Existe uma percepção cada vez mais comum de que saber escrever bons prompts será suficiente para transformar alguém em especialista em tecnologia.
Discordo parcialmente dessa ideia.
Saber formular uma solicitação clara é importante, mas isso representa apenas uma parte do processo.
Se uma pessoa solicita a uma IA que crie um ambiente de alta disponibilidade no Azure, precisa compreender o conceito de Zona de Disponibilidade, os limites de cada serviço, as dependências de rede, as permissões necessárias e os riscos de concentrar componentes críticos em um único ponto de falha.
Se solicita a criação de uma infraestrutura no GCP, precisa compreender elementos como IAM, redes VPC, políticas de firewall, escalabilidade, observabilidade e gestão de custos.
Se desenvolve uma IA local conectada a ferramentas de segurança, precisa compreender os limites de execução, o tratamento de credenciais, o isolamento dos processos e a validação das respostas.
Sem esse conhecimento, a pessoa corre o risco de construir soluções visualmente impressionantes, mas tecnicamente frágeis.
A Inteligência Artificial pode reduzir drasticamente o tempo necessário para executar determinadas atividades, mas não elimina a necessidade de compreender o problema.
Na realidade, acredito que estamos assistindo a uma valorização de algo que sempre foi fundamental na tecnologia: a capacidade de relacionar diferentes áreas do conhecimento.
Infraestrutura, programação, redes, segurança, Cloud, automação e dados estão cada vez mais próximos.
O profissional que conseguir conectar esses conhecimentos terá condições de utilizar a IA não apenas como um assistente, mas como uma ferramenta de engenharia.
Considerações finais
Quando comecei a experimentar o BitNet, minha intenção era compreender os limites de uma Inteligência Artificial executada localmente.
Queria descobrir até que ponto seria possível construir algo funcional sem depender continuamente de modelos hospedados em grandes datacenters.
Acabei encontrando perguntas muito mais interessantes do que imaginava.
Até onde podemos simplificar uma arquitetura de IA sem comprometer sua utilidade? Quais atividades realmente necessitam de modelos de grande porte? Como transformar documentação técnica em conhecimento consultável? Qual é o equilíbrio entre autonomia, custo computacional e segurança?
Meu pequeno assistente local de cibersegurança ainda está longe de ser uma solução perfeita. Entretanto, ele demonstra que não precisamos necessariamente começar com uma infraestrutura complexa para experimentar aplicações práticas de Inteligência Artificial.
Às vezes, um modelo compacto, uma base de conhecimento bem construída e algumas integrações cuidadosamente desenvolvidas são suficientes para entregar valor.
E talvez essa seja uma das transformações mais importantes deste momento.
Durante muitos anos, aprendemos a dimensionar servidores, configurar sistemas operacionais, desenvolver aplicações e administrar redes.
Agora estamos aprendendo a construir sistemas capazes de nos ajudar a executar todas essas tarefas.
Isso não representa o fim da engenharia de tecnologia. Representa uma mudança profunda na maneira como ela será praticada.
A pergunta deixou de ser apenas o que conseguimos construir com Inteligência Artificial. Agora precisamos entender o que realmente vale a pena construir, quanto custa manter essa inteligência e quanto controle desejamos ter sobre ela.
E, para mim, essa discussão está apenas começando.
Referências técnicas para aprofundamento
As reflexões e a experiência relatadas neste artigo são autorais. Para aprofundar os conceitos e tecnologias mencionados, recomendo as seguintes referências oficiais:
Microsoft — BitNet e bitnet.cpp: arquitetura, modelos e framework de inferência local.
Microsoft Learn — Retrieval-Augmented Generation: conceitos, indexação e recuperação de conhecimento.
Microsoft Learn — GitHub Copilot para operações em Cloud: geração de infraestrutura como código e automação no Azure.
Microsoft Learn — Infrastructure as Code: Bicep, Terraform e implantação de recursos.
Google Cloud — GenAI Factory: arquiteturas de referência e automação de infraestrutura no GCP.