Transição de carreira para TI: redes, segurança, nuvem ou gestão? Por qual trilha começar?

A segurança de APIs corporativas é uma prioridade para organizações que operam aplicações distribuídas e arquiteturas baseadas em microsserviços, sobretudo diante da proliferação das chamadas Zombie APIs. Em linhas gerais, o termo designa interfaces que já cumpriram sua função dentro da aplicação e foram substituídas por versões mais recentes ou abandonadas ao longo da evolução do software, mas permanecem ativas em produção sem manutenção, atualização de segurança ou monitoramento adequado. Ao longo deste artigo, analisaremos como surgem as Zombie APIs, por que elas figuram entre os riscos mais negligenciados em arquiteturas de microsserviços, como se relacionam com as vulnerabilidades descritas no OWASP API Security Top 10 e quais práticas técnicas permitem identificá-las, controlá-las e removê-las sem comprometer aplicações em produção. __________________________________________ Você também pode gostar: O que é arquitetura de microsserviços e quais são seus principais benefícios? O que são Zombie APIs e por que elas se multiplicam em arquiteturas de microsserviços? A existência de Zombie APIs (ou APIs abandonadas) está diretamente relacionada com o próprio modelo de desenvolvimento adotado pelas aplicações modernas.  À medida que organizações ampliam o uso de microsserviços, aplicações distribuídas e integrações entre sistemas, o número de endpoints publicados cresce em velocidade superior à capacidade das equipes de catalogá-los, revisar seu ciclo de vida e validar continuamente quais APIs ainda precisam permanecer disponíveis. Como consequência, diferentes versões de um mesmo serviço acabam coexistindo na infraestrutura. Algumas delas permanecem em operação para preservar integrações legadas; outras simplesmente não são monitoradas durante ciclos de refatoração, migração ou substituição tecnológica. Em ambos os casos, continuam acessíveis em produção, ainda que já não façam parte do desenvolvimento ativo da aplicação. Essa falta de visibilidade tende a comprometer a governança sobre o inventário de APIs, principalmente em Kubernetes, contêineres pouco utilizados, máquinas virtuais legadas ou implantações antigas.  Na maior parte das vezes, esses ambientes podem manter endpoints expostos por longos períodos sem que eles apareçam na documentação oficial, nos catálogos de APIs ou mesmo nos pipelines atuais de CI/CD. Para um agente malicioso, esse tipo de ativo representa uma oportunidade particularmente atrativa.  Enquanto aplicações recentes costumam incorporar mecanismos modernos de autenticação, autorização, observabilidade e proteção contra abuso, uma API publicada anos antes pode continuar operando com controles compatíveis apenas com os padrões de segurança existentes quando foi desenvolvida. Uma interface disponibilizada em 2021, por exemplo, pode permanecer acessível sem autenticação baseada em OAuth 2.0 ou OpenID Connect, sem limitação de requisições (rate limiting), utilizando bibliotecas que já possuem vulnerabilidades conhecidas ou sem nenhum monitoramento centralizado de tráfego.  Esse cenário explica por que a presença de Zombie APIs costuma estar associada a diversas categorias descritas pelo OWASP API Security Top 10, a principal referência internacional para segurança de APIs.  Em vez de constituírem uma vulnerabilidade específica, elas frequentemente concentram condições que favorecem diferentes técnicas de exploração.  Além disso, identificar esse tipo de endpoint costuma exigir menos esforço do que explorar serviços continuamente atualizados e submetidos a processos modernos de segurança. Por esse motivo, a segurança de APIs corporativas exige uma abordagem que ultrapassa a proteção das aplicações atualmente desenvolvidas.  Inventariar interfaces, acompanhar seu ciclo de vida, controlar versionamentos e executar processos seguros de descomissionamento são práticas que reduzem a exposição da organização e fortalecem a governança sobre ambientes cada vez mais distribuídos. _________________________________________ Você também pode gostar: Por que a nuvem ficou cara? O papel do edge computing nos custos de TI Zombie APIs ×  Shadow APIs: por que a diferença importa? Embora ambos os conceitos representem riscos relevantes para a segurança de APIs corporativas, eles possuem origens bastante diferentes. Zombie APIs Shadow APIs Foram APIs oficiais da organização. São APIs criadas sem conhecimento ou aprovação dos processos formais de governança. Estão documentadas em algum momento da história do projeto. Frequentemente nunca foram documentadas oficialmente. Permanecem ativas após serem substituídas ou abandonadas. Surgem paralelamente aos fluxos oficiais de desenvolvimento. O principal problema é a ausência de descomissionamento. O principal problema é a ausência de visibilidade e controle institucional. Na prática, uma organização pode conviver simultaneamente com ambos os cenários. Enquanto as Shadow APIs aumentam a superfície de ataque por escaparem completamente da governança corporativa, as Zombie APIs representam um risco adicional justamente porque transmitem uma falsa percepção de controle.  Muitas vezes, elas foram desenvolvidas segundo os padrões vigentes da época, mas permaneceram expostas mesmo após mudanças significativas nas políticas de autenticação, criptografia, registro de eventos e controle de acesso. Essa combinação faz com que ativos esquecidos se tornem alguns dos alvos mais atrativos para cibercriminosos. 3 prejuízos de uma API esquecida 1) Improper Inventory Management Entre todas as categorias do OWASP API Security Top 10, a que mais se relaciona com Zombie APIs é a Improper Inventory Management. Ela descreve situações em que a organização não mantém um inventário completo e continuamente atualizado das APIs expostas, das versões existentes, dos ambientes nos quais estão implantadas e dos respectivos responsáveis técnicos. Isso significa que equipes de desenvolvimento, infraestrutura e segurança passam a trabalhar com percepções diferentes da superfície real de exposição da organização. De um lado, os catálogos internos indicam determinado conjunto de serviços; do outro, versões antigas permanecem respondendo em ambientes de produção, homologação ou contingência, muitas vezes acessíveis diretamente pela internet.  Sem visibilidade, essas interfaces não integram rotinas de atualização, testes de segurança, monitoramento e resposta a incidentes. Ou seja, torna-se impossível proteger aquilo cuja existência sequer é conhecida. 2) Broken Object Level Authorization (BOLA)  Outra vulnerabilidade frequentemente encontrada em Zombie APIs está relacionada com a Broken Object Level Authorization (BOLA), considerada há vários anos uma das categorias mais críticas do OWASP API Security Top 10. Esse problema ocorre quando a aplicação não verifica corretamente se o usuário autenticado possui autorização para acessar determinado recurso específico. Em APIs antigas, é comum encontrar validações implementadas antes da adoção de modelos mais robustos de autorização, como políticas baseadas em escopos (scopes), claims de identidade ou controles centralizados de acesso. Como consequência, basta que um agente malicioso altere parâmetros presentes na própria requisição – como identificadores numéricos ou UUIDs – para tentar acessar registros pertencentes a outros usuários. Quando a interface permanece esquecida durante anos, essa vulnerabilidade pode persistir sem nenhuma revisão de código, aumentando significativamente o potencial de exposição de informações sensíveis. 3) Expansão da superfície de ataque A permanência de Zombie APIs também favorece problemas relacionados com autenticação, criptografia, limitação de requisições (rate limiting) e gerenciamento de sessões. Enquanto novas versões da aplicação passam a utilizar O Auth 2.0, OpenID Connect, autenticação multifator, rotação de credenciais e políticas modernas de observabilidade, interfaces antigas frequentemente continuam operando com mecanismos legados ou até mesmo sem autenticação obrigatória para determinadas operações. Com isso,  ataques direcionados não concentram esforços sobre APIs continuamente atualizadas, procurando, assim, endpoints pouco monitorados, versões antigas documentadas em repositórios públicos, URLs esquecidas em históricos de aplicações ou interfaces que permanecem acessíveis por razões de compatibilidade. Em muitos incidentes, o vetor inicial não está na tecnologia mais recente implementada pela organização, mas justamente na infraestrutura que deixou de receber atenção ao longo dos anos. Como localizar Zombie APIs antes que elas se tornem um incidente de segurança? Identificar uma API abandonada exige uma estratégia de descoberta contínua. Esperar que todas as interfaces estejam corretamente documentadas costuma ser insuficiente em ambientes compostos por dezenas ou centenas de microsserviços, múltiplas equipes de desenvolvimento e ciclos frequentes de implantação. Por esse motivo, organizações com maior maturidade em segurança de APIs corporativas tratam a descoberta de endpoints como um processo permanente de governança, integrando observabilidade, inventário de ativos e gestão do ciclo de vida das APIs. Embora existam diversas ferramentas capazes de automatizar parte desse trabalho, três práticas técnicas concentram os melhores resultados na redução da superfície de ataque. 1. Descoberta ativa de APIs (API Discovery) O primeiro passo consiste em mapear todas as interfaces efetivamente acessíveis na infraestrutura, independentemente de constarem ou não da documentação oficial. Essa atividade combina informações provenientes de diferentes fontes, como logs de balanceadores de carga, registros de API Gateway, telemetria de aplicações, capturas de tráfego de rede, inventários de Kubernetes, ambientes em nuvem e ferramentas especializadas de API Discovery. O objetivo não é exclusivamente listar endpoints existentes, mas responder perguntas fundamentais para a governança: É comum que esse processo revele APIs desconhecidas pelas próprias equipes responsáveis pela plataforma. 2. Centralizar o controle por meio de um API Gateway Após identificar os endpoints existentes, o próximo passo consiste em garantir que todo o tráfego passe por um ponto único de controle. Ferramentas como AWS API Gateway e outras soluções equivalentes permitem centralizar autenticação, autorização, limitação de requisições, registro de eventos, observabilidade e aplicação uniforme de políticas de segurança. Além de simplificar a administração dos serviços, essa abordagem reduz significativamente a possibilidade de uma API permanecer exposta sem os mesmos controles aplicados ao restante da plataforma. Outro benefício importante é a construção de um inventário continuamente atualizado, já que todas as chamadas passam a ser registradas e monitoradas pelo gateway. 3. Estruturar um processo seguro de descomissionamento Eliminar uma Zombie API não significa simplesmente desligar um serviço. Em ambientes corporativos, uma interface aparentemente obsoleta pode continuar sendo utilizada por aplicações legadas, parceiros comerciais, integrações externas ou sistemas internos cuja documentação já não reflete a realidade operacional. Por essa razão, o descomissionamento deve ocorrer de forma planejada. Boas práticas incluem publicar avisos de depreciação (Deprecation Headers), monitorar a volumetria de chamadas durante um período previamente definido, comunicar consumidores da API, disponibilizar alternativas compatíveis e realizar a remoção definitiva apenas quando houver evidências de que a migração foi concluída. Esse processo reduz o risco de indisponibilidade e permite retirar ativos antigos da infraestrutura sem comprometer a continuidade dos serviços. Por que eliminar APIs esquecidas não encerra o problema A remoção de APIs abandonadas reduz a superfície de ataque existente, mas não impede que novos endpoints esquecidos surjam à medida que a arquitetura evolui.  Em ambientes orientados por microsserviços, cada novo ciclo de desenvolvimento, atualização de versões ou integração entre aplicações pode introduzir interfaces adicionais, ampliando continuamente o inventário tecnológico da organização. Por esse motivo, a segurança de APIs corporativas precisa ser tratada como um processo permanente de governança, e não como uma iniciativa pontual conduzida após a identificação de vulnerabilidades. Essa governança envolve estabelecer critérios claros para publicação, versionamento, documentação, monitoramento e descomissionamento de APIs desde o início do seu ciclo de vida.  Quando essas etapas passam a integrar os fluxos de desenvolvimento, operações e segurança, torna-se possível reduzir significativamente o risco de que interfaces antigas permaneçam acessíveis sem o conhecimento das equipes responsáveis. Para isso, é necessário a integração entre diferentes áreas da organização. Arquitetos de software, desenvolvedores, especialistas em DevSecOps, equipes de infraestrutura e profissionais de AppSec precisam compartilhar um inventário único de ativos, definir responsáveis por cada interface publicada e incorporar verificações automáticas durante os pipelines de integração e entrega contínuas (CI/CD). Esse modelo permite identificar desvios antes que eles alcancem a produção, facilita auditorias de segurança e fortalece a rastreabilidade de todo o ciclo de vida das APIs. Capacitação técnica fortalece a segurança de APIs corporativas Ferramentas de descoberta automática, API Gateways e plataformas de observabilidade representam componentes importantes da estratégia de proteção das aplicações.  Entretanto, sua efetividade depende da capacidade das equipes de compreender como essas tecnologias se integram à arquitetura da organização e quais decisões técnicas devem orientar sua configuração e operação. A gestão segura do ciclo de vida das APIs exige conhecimentos que abrangem protocolos de rede, infraestrutura, segurança de aplicações, arquiteturas distribuídas, observabilidade e práticas de DevSecOps.  Sem esse domínio, torna-se mais difícil identificar riscos, interpretar alertas produzidos pelas ferramentas e estabelecer políticas consistentes de governança. Nesse contexto, a capacitação técnica contínua amplia a autonomia das equipes para avaliar ambientes complexos, reduzir dependências operacionais e responder com maior rapidez às mudanças inerentes ao desenvolvimento moderno de software. A Escola Superior de Redes (ESR) oferece trilhas de formação voltadas justamente para esses desafios, reunindo cursos em infraestrutura de redes, arquitetura TCP/IP, segurança da informação, computação em nuvem e DevSecOps.  Essa formação contribui para que profissionais desenvolvam uma visão integrada da infraestrutura que sustenta aplicações distribuídas e das práticas necessárias para protegê-las ao longo de todo o seu ciclo de vida. Quero conhecer as Trilhas de Conhecimento ESR Perguntas frequentes sobre segurança de APIs corporativas 1. O que é uma Zombie API? Uma Zombie API é uma interface que permanece ativa em produção mesmo após ter sido substituída ou retirada do ciclo de desenvolvimento. Como deixa de receber manutenção, correções de segurança e monitoramento, pode ampliar a superfície de ataque e dificultar a governança das APIs da organização. 2. Qual é a diferença entre Zombie API e Shadow API? A Zombie API foi criada oficialmente pela organização e permaneceu ativa após ser abandonada. Já a Shadow API é desenvolvida sem passar pelos processos formais de governança, muitas vezes sem documentação ou conhecimento da equipe de segurança. Ambas representam riscos, mas possuem origens diferentes. 3. Por que Zombie APIs representam um risco à segurança de APIs corporativas? Porque podem permanecer expostas utilizando mecanismos de autenticação, autorização e criptografia desatualizados. Além disso, normalmente ficam fora das rotinas de monitoramento, atualização e testes de segurança, tornando-se um alvo atrativo para agentes maliciosos. 4. Como identificar Zombie APIs? A identificação envolve práticas de API Discovery, análise de logs, monitoramento de tráfego, inventário de endpoints e comparação entre as APIs em produção e a documentação oficial. O objetivo é localizar interfaces que continuam acessíveis, mas já não fazem parte do ciclo ativo de desenvolvimento. 5. O OWASP API Security Top 10 cita Zombie APIs? Não diretamente. Entretanto, Zombie APIs costumam estar associadas a categorias como Improper Inventory Management e Broken Object Level Authorization (BOLA), pois frequentemente permanecem sem governança, revisão de segurança e controle adequado de acesso. 6. Um API Gateway elimina Zombie APIs? Não. O API Gateway centraliza a autenticação, a autorização, o monitoramento e a aplicação de políticas de segurança, mas não substitui o inventário de APIs nem o gerenciamento do ciclo de vida dos endpoints. A descoberta e o descomissionamento continuam sendo necessários. 7. Como remover uma Zombie API com segurança? O descomissionamento deve ser gradual. Recomenda-se comunicar a API aos consumidores, publicar avisos de depreciação, monitorar o volume de chamadas e remover a interface apenas quando houver evidências de que ela não é mais utilizada. 8. Como evitar o surgimento de novas Zombie APIs? A prevenção depende de governança contínua. Inventário atualizado, documentação, API Discovery, revisão periódica de endpoints e integração entre desenvolvimento, infraestrutura e segurança reduzem significativamente a permanência de APIs obsoletas em produção. Quero conhecer as Trilhas de Conhecimento ESR

FinOps – termo originado da combinação entre Finanças e DevOps – é um framework operacional e uma prática cultural que buscam maximizar o valor de negócio gerado pelos investimentos em tecnologia. A abordagem promove decisões oportunas baseadas em dados e estabelece responsabilidade financeira compartilhada por meio da colaboração entre engenharia, finanças, produtos e áreas de negócio. Embora tenha se consolidado inicialmente na gestão de custos em nuvem, seu escopo pode abranger SaaS, licenciamento, data centers, plataformas de dados, inteligência artificial e outras categorias de tecnologia. Quando aplicado à gestão de custos em nuvem, o FinOps passa a responder a um dos principais desafios da TI corporativa – manter a eficiência operacional em um modelo de consumo variável e descentralizado. Esse cenário está diretamente ligado à forma como a nuvem é utilizada. O modelo sob demanda ampliou a capacidade de escala e trouxe flexibilidade para os negócios, mas também introduziu uma camada adicional de complexidade financeira. Recursos são provisionados em segundos e, nesse mesmo ritmo, acumulam custos que nem sempre são facilmente rastreáveis, atribuíveis ou previsíveis. À medida que esse formato se consolida, surgem desalinhamentos dentro das organizações. As equipes técnicas seguem orientadas por critérios como performance, disponibilidade e arquitetura, enquanto a área financeira lida com oscilações de custo que não acompanham, na mesma proporção, o nível de visibilidade necessário para análise e controle. Esse descompasso se reflete nas faturas mensais com valores elevados, nas variações inesperadas e na dificuldade em estabelecer uma relação direta entre consumo técnico e geração de valor para o negócio. Nesse ambiente, o objetivo do FinOps não é simplesmente gastar menos, mas assegurar que cada unidade monetária investida em tecnologia produza o melhor resultado possível para o negócio. Uma ampliação de custos pode ser justificável quando estiver associada, por exemplo, ao crescimento de receita, à melhoria da experiência do cliente, à redução de riscos ou ao aumento mensurável da capacidade operacional. Diante desse contexto, o FinOps se consolida como uma abordagem estruturada para organizar a gestão de custos em cloud. A prática estabelece uma dinâmica em que decisões técnicas passam a incorporar impacto financeiro, ao mesmo tempo que decisões orçamentárias passam a considerar padrões reais de consumo. Ao longo deste artigo, serão detalhados os fundamentos do FinOps, sua aplicação prática na gestão de custos em cloud e os impactos dessa abordagem na forma como as áreas de tecnologia e finanças operam dentro das organizações. O que é FinOps e por que ele é diferente da gestão tradicional de custos em TI? A gestão de custos em tecnologia sempre existiu, mas o modelo em que ela operava mudou de forma significativa com a adoção da nuvem. No cenário tradicional, baseado em infraestrutura própria, os investimentos eram realizados de forma antecipada. Servidores, armazenamento e licenças eram adquiridos como ativos, com previsibilidade de custo e baixa variação ao longo do tempo. Esse modelo, conhecido como CapEx (capital expenditure), concentrava as decisões financeiras em ciclos mais longos e centralizados. Com a adoção da computação em nuvem, muitas organizações passaram de um modelo predominantemente baseado em investimentos antecipados para outro com maior participação de despesas operacionais e cobrança associada ao consumo.  Os recursos passam a ser predominantemente provisionados e consumidos sob demanda, com cobrança relacionada com o uso. No entanto, é importante frisar que tal mudança não elimina completamente o CapEx nem torna todo gasto em nuvem automaticamente classificável como OpEx, pois o tratamento contábil depende da natureza da contratação e das normas aplicáveis. Nos ambientes híbridos, elementos de CapEx e OpEx podem coexistir.  Assim, a mudança altera o ponto de controle. Em vez de decisões concentradas na aquisição de infraestrutura, os custos são influenciados diariamente por escolhas técnicas, como configuração de ambientes, volume de processamento, armazenamento e tráfego de dados. Nesse ponto, o FinOps se diferencia da gestão tradicional. Isso porque a prática reorganiza a responsabilidade sobre custos, distribuindo-a entre as equipes envolvidas no uso da tecnologia. Engenheiros, arquitetos e líderes de produto passam a atuar com maior consciência financeira, enquanto a área de finanças ganha visibilidade sobre padrões de consumo e consegue atuar de forma mais estratégica. É um alinhamento responsável por reduzir a distância entre quem consome recursos e quem responde pelo orçamento, criando uma dinâmica mais transparente e eficiente. Para profissionais técnicos, isso representa uma ampliação de escopo. As decisões são avaliadas por critérios de performance e também impacto financeiro. Já para áreas de governança e controle, há maior capacidade de previsão, acompanhamento e ajuste. O FinOps, portanto, não substitui a gestão de custos tradicional, ele a adapta a um ambiente em que consumo e gasto ocorrem de forma simultânea e distribuída. Essa adaptação também amplia o objeto da gestão financeira, que passa a considerar conjuntamente custo, eficiência operacional e valor de negócio, evitando que a redução de despesas seja tratada como objetivo isolado. As três fases do ciclo FinOps A aplicação de FinOps na gestão de custos em nuvem não se dá de forma pontual ou isolada. Trata-se de um processo contínuo, estruturado em etapas que se retroalimentam e permitem a evolução progressiva da maturidade financeira da operação. O ciclo FinOps é geralmente apresentado em três fases: Informar (Inform), Otimizar (Optimize) e Operar (Operate), as quais não constituem uma sequência rígida. Elas são iterativas, podendo ocorrer simultaneamente em diferentes áreas; além de repetidas continuamente à medida que a organização evolui. Cada capacidade FinOps também pode apresentar um nível diferente de maturidade. A seguir, detalhamos as fases e seus objetivos. Informar (Inform): dar visibilidade ao consumo A primeira etapa do FinOps para gestão de custos em nuvem está relacionada com a compreensão do ambiente. Em muitas organizações, a dificuldade de controlar custos não está na ausência de ferramentas, mas na falta de visibilidade estruturada do uso dos recursos. Sem clareza sobre quem consome, quanto consome e com qual finalidade, qualquer tentativa de controle tende a ser superficial. Por isso, o foco inicial está na organização dos dados. Essa etapa envolve práticas como: ●  definição de políticas de marcação e classificação de recursos por meio de tags (tagging); ●  estruturação de contas e centros de custo; ●  utilização assinaturas, projetos, labels, namespaces e outros metadados de faturamento; ●  definição de regras para distribuição de custos compartilhados; ●  estabelecimento de critérios de alocação de custos por produto, serviço, unidade ou centro de custo; ●  consolidação de relatórios financeiros por projeto, equipe ou produto. Com essas informações organizadas, torna-se possível identificar padrões de consumo, acompanhar variações e iniciar a construção de previsibilidade. Otimizar (Optimize): ajustar uso, tarifas e compromissos Com a visibilidade estabelecida, a próxima etapa concentra-se na eficiência. Nesse ponto, a análise dos dados permite identificar distorções no uso dos recursos, como ambientes superdimensionados, instâncias ociosas ou configurações desalinhadas com a real demanda. As ações mais comuns incluem o redimensionamento de recursos (rightsizing), o desligamento de ambientes não utilizados, a otimização de armazenamento, a revisão da arquitetura e a adoção de descontos baseados em compromisso de uso ou gasto, como Reserved Instances, Savings Plans e modelos equivalentes dos provedores. Também podem ser realizadas revisões de contratos e condições comerciais. Aqui, os compromissos de uso ou gasto devem ser cuidadosamente dimensionados – afinal, um valor contratado acima da demanda real pode converter uma economia potencial em desperdício. Por isso, cabe acompanhar de perto os indicadores de cobertura, utilização e vigência dos acordos assumidos. Esta etapa exige proximidade entre equipes técnicas e áreas de negócio, já que ajustes operacionais podem impactar diretamente a experiência do usuário ou a entrega de serviços. 👉 Dica extra da ESR: Gestão de contratos de TI: 5 erros que drenam o orçamento das empresas Operar (Operate): integrar decisões financeiras à rotina A última etapa consolida o FinOps como prática contínua dentro da organização. É a fase em que a gestão financeira não é mais predominantemente reativa, integrando a rotina das equipes. Além disso, o acompanhamento ocorre de forma recorrente, combinando indicadores financeiros, técnicos, operacionais e de valor de negócio. As decisões técnicas passam a considerar o impacto financeiro, com acompanhamento contínuo de orçamento, consumo, previsões e resultados, bem como o alinhamento entre tecnologia, finanças, produtos e áreas de negócio. Ao incorporar custos no dia a dia da operação, a organização passa a atuar com maior controle e consistência, reduzindo variações inesperadas e melhorando a alocação de recursos. Esse ciclo não se encerra. Conforme a operação evolui, novas oportunidades de ajuste surgem, exigindo revisões constantes e aprofundamento das práticas adotadas. 👉 Dica extra da ESR: O que é Edge Computing e qual a sua finalidade? Benefícios que vão além da redução de custos A redução de gastos costuma ser o ponto de entrada para a adoção de FinOps, mas os impactos da prática se estendem para dimensões mais amplas da operação. À medida que a gestão de custos em nuvem se torna estruturada, outros ganhos aparecem de forma consistente. Um dos primeiros efeitos é a melhoria na tomada de decisão. Com acesso a dados mais claros sobre consumo e custo, equipes conseguem avaliar cenários com maior precisão. Isso permite priorizar iniciativas com base não apenas em viabilidade técnica, mas também em impacto financeiro e retorno esperado. Outro aspecto relevante é o aumento da previsibilidade orçamentária. Mesmo em um modelo de consumo variável, a organização passa a identificar padrões, antecipar variações e ajustar o uso de recursos de forma mais controlada. Esse movimento reduz a exposição a surpresas financeiras e facilita o planejamento. Para apoiar a previsibilidade, o FinOps utiliza práticas como forecast contínuo, comparação entre orçamento e realizado, análise de variações, identificação de sazonalidades e atualização periódica das previsões. Também são utilizados alertas e mecanismos de detecção de anomalias para identificar aumentos inesperados de consumo e permitir o tratamento tempestivo dos desvios. A adoção de FinOps também contribui para maior responsabilização das equipes. Quando os custos não são um dado distante e fazem parte da rotina, decisões técnicas se tornam mais conscientes. Esse alinhamento tende a reduzir desperdícios e melhorar a eficiência no uso da infraestrutura. Além disso, há impacto direto na capacidade de escalar operações. Com visibilidade e controle, o crescimento deixa de gerar aumentos desproporcionais de custo. A expansão passa a ocorrer de forma mais equilibrada, sustentada por dados e ajustes contínuos. Por fim, a prática favorece um ambiente mais integrado entre as áreas. Nessa dinâmica, tecnologia, finanças e negócio operam com maior alinhamento, reduzindo conflitos e aumentando a clareza sobre prioridades e restrições. Esses efeitos indicam que o FinOps não atua apenas nos custos, mas na forma como a organização toma decisões e conduz sua operação em ambientes digitais. 👉 Dica extra da ESR: Computação quântica: o que está por trás dessa tecnologia e quais suas tendências? Comparativo: gestão tradicional de custos vs. FinOps Aspecto Gestão tradicional de custos em TI FinOps (gestão de valor da tecnologia)  Modelo financeiro CapEx (investimento antecipado) OpEx (consumo sob demanda) Previsibilidade Alta, baseada em aquisição Variável, baseada em uso contínuo Responsabilidade Centralizada (financeiro/gestão) Compartilhada (TI, finanças e negócio) Frequência de decisão Pontual (ciclos longos) Contínua (decisões diárias) Visibilidade de custos Consolidada e estática Dinâmica e granular Relação com uso Indireta Direta (uso = custo) Papel do time técnico Foco em performance Foco em performance + impacto financeiro Controle de desperdício Limitado Contínuo e orientado por dados Escalabilidade Limitada à infraestrutura adquirida Alta, com necessidade de governança Integração entre áreas Baixa Alta (engenharia, finanças e negócio) Situações comuns de desperdício em nuvem e como o FinOps atua  A dificuldade de controlar custos na nuvem costuma estar associada a padrões recorrentes de uso ineficiente do recurso. Esse cenário aparece em diferentes tipos de operação e, quando não é identificado, tende a escalar rapidamente junto com o ambiente. A seguir, selecionamos alguns exemplos comuns e como a aplicação de FinOps atua diretamente na correção desses desvios para que o conhecimento adquirido até aqui se torne mais palpável: Situação comum Impacto no custo Como o FinOps atua  Instâncias superdimensionadas Pagamento por capacidade não utilizada Rightsizing com base em uso real Ambientes de teste ativos fora do horário Consumo contínuo sem necessidade operacional Automação para desligamento programado Recursos sem identificação (sem tags) Dificuldade de rastrear custos por área ou projeto Implementação de políticas de tagging Armazenamento não otimizado Acúmulo de dados irrelevantes ou pouco acessados Classificação e uso de tiers mais econômicos Uso excessivo de recursos sob demanda Custos mais elevados no longo prazo Adoção de instâncias reservadas ou savings plans Falta de governança em múltiplas contas Custos descentralizados e sem controle consolidado Estruturação de contas e centros de custo Transferência de dados entre regiões Custos elevados de tráfego Revisão de arquitetura e localização de workloads Considere uma empresa que mantém 20 instâncias de desenvolvimento ativas continuamente, ao custo médio de R$ 800 mensais por instância.  O custo anual desses recursos é de R$ 192 mil. Caso os ambientes sejam necessários somente durante 12 horas por dia, em dias úteis, uma política automatizada de desligamento poderá reduzir significativamente o período faturável.  Antes da implantação do recurso, a equipe deverá validar dependências, tempo de inicialização, requisitos de disponibilidade e possíveis compromissos de consumo já contratados.  O resultado deverá ser medido pela economia líquida, descontando custos de automação e eventuais impactos operacionais.  Esses exemplos evidenciam que o desperdício em cloud raramente está ligado a falhas técnicas isoladas. Na maior parte dos casos, ele decorre da ausência de processos claros, de visibilidade estruturada e de alinhamento entre as áreas envolvidas no consumo dos recursos. Ao aplicar FinOps, a organização passa a tratar esses pontos de forma sistemática, criando rotinas de análise, ajustes e acompanhamento contínuo, o que reduz perdas e melhora a eficiência ao longo do tempo. Gestão de custos como competência central na TI A adoção de cloud redefiniu a forma como a infraestrutura é consumida e, com isso, alterou também a lógica de gestão dentro das organizações. Os custos deixam de se apresentar como elementos predominantemente estáticos, associados à aquisição de ativos, e passam a acompanhar, de maneira mais direta, o comportamento das aplicações e o consumo dos serviços.  Esse movimento exigiu e ainda exige um novo tipo de atuação, no qual decisões técnicas e financeiras caminham de forma coordenada. O FinOps organiza essa dinâmica ao estabelecer práticas que conectam consumo, custo, eficiência e valor de negócio.   Ao trazer visibilidade, distribuir responsabilidades e integrar áreas, a gestão de custos em nuvem passa a operar com maior consistência e controle. Esse cenário já impacta o perfil dos profissionais mais demandados pelo mercado. O conhecimento técnico continua essencial, mas a capacidade de compreender o impacto financeiro das decisões em cloud se tornou um diferencial relevante, especialmente em ambientes que operam com escala e alta complexidade. Desenvolva a competência FinOps com a ESR A Escola Superior de Redes (ESR) oferece formações voltadas para gestão e governança de tecnologia, preparando profissionais para atuar em cenários que exigem integração entre engenharia, finanças e negócio. Trata-se de uma trilha de conhecimento importante, tendo em vista que a implementação do FinOps depende da participação coordenada de diferentes funções.  A liderança executiva fornece o patrocínio e o direcionamento; a equipe central de FinOps organiza as práticas, os indicadores e os ritos de acompanhamento; os times de engenharia e arquitetura avaliam a eficiência técnica; finanças e controladoria apoiam o orçamento, o forecast e a alocação; o setor de compras gerencia os contratos e os fornecedores; e as áreas de produto e negócio relacionam os custos com os resultados alcançados.  Segurança, sustentabilidade e gestão de ativos também podem participar conforme o escopo tecnológico da organização. Ou seja, há o envolvimento holístico das equipes e dos colaboradores. Ao longo dos cursos, temas como controle de custos em nuvem, contratos com provedores e práticas de governança são abordados de forma aplicada, conectando teoria e prática. O mercado demanda profissionais capazes de gerenciar valor, não apenas infraestrutura. Desenvolva essa competência e prepare-se para atuar com FinOps na prática. QUERO ME INSCREVER NAS PRÓXIMAS TURMAS FAQ – Perguntas frequentes sobre FinOps na prática. Dúvidas comuns sobre gestão de custos em nuvem. O que é FinOps na prática? FinOps é um framework operacional e uma prática cultural que conecta engenharia, finanças, produtos e áreas de negócio para maximizar o valor dos investimentos em tecnologia. Na prática, envolve dar visibilidade ao consumo, alocar custos, elaborar previsões, otimizar uso e tarifas e avaliar os resultados tecnológicos em relação aos objetivos do negócio. FinOps é uma ferramenta ou uma metodologia? FinOps não é uma ferramenta específica nem apenas uma metodologia. Trata-se de um framework operacional e de uma prática cultural que combina pessoas, processos, dados e tecnologia. Ferramentas apoiam a coleta, a normalização, a análise e a automação, mas não substituem a colaboração, a governança e a responsabilidade compartilhada. Qual o principal problema que o FinOps resolve? O FinOps busca resolver a dificuldade de conectar o consumo de tecnologia ao valor produzido para o negócio. Para isso, aumenta a visibilidade dos custos, melhora a alocação e a previsibilidade, reduz desperdícios e fornece informações para decisões que equilibrem custo, desempenho, risco e resultado empresarial. Sem essa estrutura, empresas enfrentam dificuldade para prever gastos, identificar desperdícios e conectar consumo técnico a resultado financeiro. Quem deve ser responsável pelo FinOps dentro da empresa? A organização pode estabelecer uma equipe central ou um Centro de Excelência FinOps, mas essa equipe atua como facilitadora da prática. A responsabilidade pelas decisões e pelos resultados permanece distribuída entre as áreas consumidoras e gestoras da tecnologia. As equipes técnicas passam a considerar custo em suas decisões, enquanto as áreas financeiras acompanham o consumo com maior proximidade. Em organizações mais maduras, pode existir um time dedicado, mas o modelo depende da colaboração entre diferentes áreas. Quando uma empresa deve adotar o FinOps? A necessidade surge a partir do momento em que a empresa passa a operar com cloud de forma relevante. Ambientes com múltiplas aplicações, equipes distribuídas e crescimento constante de consumo tendem a apresentar maior complexidade financeira, o que torna a adoção de FinOps uma necessidade operacional. FinOps serve apenas para grandes empresas? Não. Empresas de médio porte ou em fase de crescimento também se beneficiam da prática, especialmente por conseguirem estruturar a gestão de custos antes que o ambiente se torne complexo demais. A adoção antecipada do recurso evita desperdícios e melhora a previsibilidade desde o início da operação.  Quais são os principais indicadores utilizados em FinOps? Entre os indicadores mais utilizados estão: ●  custo por produto, projeto, cliente ou unidade de negócio; ●  custo por transação, pedido, API ou workload; ●  custo por token ou inferência de inteligência artificial; ●  percentual de custos corretamente alocados; ●  utilização e cobertura de compromissos; ●  precisão do forecast; ●  variação entre orçamento e realizado; ●  desperdício identificado e evitado; ●  economia líquida gerada pelas otimizações; ●  custo em relação à receita, à margem, ao SLO ou ao nível de serviço. Essas métricas permitem relacionar consumo tecnológico, eficiência operacional e valor de negócio. FinOps ajuda apenas a reduzir custos? Não. A redução de custos pode ser um resultado importante, mas não constitui o único objetivo do FinOps. A prática busca maximizar o valor dos investimentos em tecnologia, equilibrando custo, desempenho, qualidade, risco e resultado empresarial. Em alguns casos, o aumento planejado do gasto pode ser adequado quando produz benefícios proporcionalmente superiores para o negócio. A prática também melhora a previsibilidade financeira, aumenta a eficiência operacional e permite que decisões de crescimento sejam tomadas com maior segurança. Qual a relação entre FinOps e governança de cloud? O FinOps atua como um componente da governança de cloud, focado na gestão financeira. Enquanto a governança define regras, padrões e controles, o FinOps organiza a forma como os custos são monitorados, analisados e otimizados dentro desse ambiente.  Como começar a aplicar FinOps na empresa? O primeiro passo é estruturar a visibilidade dos custos. Isso envolve organizar contas, definir políticas de identificação de recursos (tags) e consolidar dados de consumo. Com isso em mãos, é possível avançar para otimizações e, posteriormente, integrar a gestão de custos à rotina das equipes. A maturidade pode ser avaliada por meio dos níveis Crawl, Walk e Run. No nível Crawl, as práticas são iniciais, predominantemente manuais e possuem cobertura limitada. No nível Walk, os processos começam a ser padronizados e os indicadores são acompanhados regularmente. No nível Run, há maior automação, integração às decisões organizacionais e melhoria contínua. A maturidade deve ser avaliada por capacidade, pois diferentes práticas podem evoluir em ritmos distintos. Conclusão O FinOps representa uma evolução na forma como as organizações administram seus investimentos em tecnologia. Para além de controlar gastos ou reduzir desperdícios, a prática conecta decisões técnicas, financeiras e empresariais, permitindo avaliar se os recursos consumidos produzem resultados compatíveis com os objetivos organizacionais. Sua adoção exige visibilidade, responsabilidade compartilhada, indicadores, governança e melhoria contínua. Quando incorporado à rotina, o FinOps contribui para decisões mais rápidas, transparentes e orientadas ao valor. Quero conhecer as formações da ESR

Os riscos da inteligência artificial para empresas estão diretamente relacionados à forma como essas tecnologias são incorporadas ao cotidiano corporativo, muitas vezes sem critérios definidos de uso, controle e validação.  A adoção de soluções baseadas em IA, especialmente ferramentas generativas, como ChatGPT, Claude, entre outras, ampliou a capacidade operacional das organizações em diversas frentes, desde a produção de conteúdo até a análise de dados e o suporte à tomada de decisão. Um avanço que ocorreu em ritmo superior à estruturação de regras internas capazes de orientar seu uso. Para entender esse contexto, é importante considerar que, embora a inteligência artificial não tenha surgido recentemente, a forma como ela evoluiu e passou a ser utilizada mudou exponencialmente nos últimos anos. Aplicações que antes estavam restritas a projetos específicos ganharam escala e acessibilidade, sendo utilizadas por equipes diversas no dia a dia. Esse movimento, inclusive, já era observado em iniciativas anteriores ligadas a machine learning e análise de dados, como discutido por nós aqui:  Na prática, isso repercutiu em ferramentas de IA já inseridas em processos internos, análises e decisões relevantes, enquanto muitas empresas ainda não estabeleceram:  Assim, há um cenário que cria uma dinâmica recorrente, no qual a tecnologia opera dentro da organização antes que exista um modelo formal de governança de IA capaz de orientar seu uso.  A partir desse ponto, os riscos se tornam concretos, uma vez que, sem diretrizes claras, a utilização de IA ocorre de forma distribuída e pouco visível para as áreas responsáveis por tecnologia, segurança da informação e compliance.  Nesse contexto, dados corporativos podem ser inseridos em plataformas externas, decisões passam a depender de sistemas automatizados e processos críticos incorporam respostas cuja origem nem sempre é rastreável.  O ponto central, portanto, não é a tecnologia em si, mas a ausência de critérios que definam como ela deve ser utilizada dentro da organização.  Como resposta a esse cenário, algumas iniciativas regulatórias têm tomado forma. No Brasil, por exemplo, projetos de lei em discussão buscam estabelecer parâmetros para o uso da inteligência artificial, incluindo princípios de transparência, responsabilização e gestão de riscos. Isso indica que, além dos impactos operacionais e éticos, o uso de IA também passa a envolver obrigações legais.  Diante dessas questões, estruturar governança de IA é uma medida necessária e urgente para alinhar inovação, segurança e responsabilidade.  Sua empresa está pronta para esse novo momento?  Ao longo deste conteúdo, você verá:  Riscos operacionais e estratégicos da IA nas empresas A incorporação de inteligência artificial ao ambiente corporativo introduz uma série de riscos que não se limitam à tecnologia em si, mas se estendem à forma como dados, processos e decisões passam a ser conduzidos. Esses riscos costumam surgir de maneira gradual, à medida que o uso de IA se expande dentro da organização sem diretrizes claras. Abaixo, estão os principais pontos de atenção que gestores precisam considerar ao avaliar o uso de IA em suas operações. 10 riscos da inteligência artificial para empresas O uso corporativo de IA envolve um conjunto de exposições que, em muitos casos, não são percebidas no momento da adoção da ferramenta, mas se manifestam na operação, na segurança e na governança ao longo do tempo. 1. Uso de dados sensíveis em ferramentas públicas Funcionários podem inserir informações estratégicas, dados pessoais ou documentos internos em plataformas abertas de IA. Esse tipo de prática tende a resultar em perda de controle sobre dados corporativos, especialmente quando não há clareza sobre como essas informações são armazenadas, processadas ou reutilizadas pelos provedores.  2. Falta de rastreabilidade nas decisões Resultados gerados por IA nem sempre permitem identificar com precisão quais dados foram utilizados ou qual lógica levou àquela resposta. Isso dificulta auditorias, compromete a transparência e cria obstáculos relevantes em ambientes regulados. Esse risco ganha dimensão concreta quando se observa a ocorrência de conteúdos inteiramente fabricados por modelos generativos. Há registros recentes no Judiciário brasileiro em que decisões e fundamentos inexistentes foram apresentados em processos, gerando sanções por litigância de má-fé. Casos como esses evidenciam um ponto crítico – quando não há rastreabilidade, não há como validar a origem da informação nem sustentar sua confiabilidade. 3. Dependência de respostas não verificadas A ausência de rastreabilidade se conecta diretamente a outro problema: a incorporação de respostas sem validação. Modelos generativos produzem conteúdos com alto grau de coerência linguística, o que facilita sua aceitação como verdade. No entanto, essa plausibilidade não garante precisão. Quando essas respostas são integradas a relatórios, pareceres ou decisões internas sem revisão técnica, o erro deixa de ser pontual e passa a compor o fluxo operacional da empresa. O risco, nesse caso, não está apenas na resposta incorreta, mas na confiança atribuída a ela. 4. Shadow IT ampliada pelo uso de IA O uso de IA reflete em uma nova camada de shadow IT, conceito que descreve tecnologias adotadas fora da governança formal da área de TI. Na prática, colaboradores acessam ferramentas diretamente, sem avaliação prévia de segurança, compliance ou integração com os sistemas corporativos. Esse movimento fragmenta o ambiente tecnológico da organização. Diferentes áreas utilizam soluções distintas, com níveis variados de proteção, armazenamento e processamento de dados. O resultado é perda de visibilidade sobre o que está em uso, dificuldade de aplicar políticas de segurança e ausência de controle sobre como informações corporativas circulam fora dos ambientes oficiais. 5. Exposição a riscos de segurança da informação A utilização de IA fora de diretrizes estruturadas de governança de IA compromete diretamente os controles de segurança da informação. Dados podem ser transferidos para ambientes externos, processados por terceiros e armazenados fora das políticas definidas pela organização, o que entra em conflito com práticas alinhadas a normas como a ISO/IEC 27001. Nesse contexto, o problema não está apenas na tecnologia, mas na quebra de controles já estabelecidos. A IA cria novos fluxos de dados que, se não forem mapeados e protegidos, ampliam a superfície de exposição a incidentes. 6. Decisões automatizadas sem supervisão adequada A incorporação de IA em processos internos altera a forma como decisões são produzidas. Quando não há definição clara de revisão humana, sistemas automatizados passam a influenciar resultados sem que exista validação proporcional ao impacto da decisão. Em áreas como jurídico, financeiro ou atendimento, isso pode significar desde recomendações equivocadas até respostas incorretas a clientes ou análises inconsistentes utilizadas como base para decisões estratégicas. O risco se intensifica quando a automação ocorre de forma silenciosa, sem que a organização tenha mapeado onde a IA está sendo utilizada. 7. Viés algorítmico e impacto reputacional Modelos de IA refletem padrões presentes nos dados com os quais foram treinados. Isso inclui vieses históricos, distorções e desigualdades que podem ser reproduzidas nas respostas e decisões geradas. Em ambientes corporativos, esse risco se manifesta em processos de seleção, análise de crédito, priorização de atendimento ou qualquer outro contexto em que a IA interfira na tomada de decisão. Além das implicações éticas, há impacto direto na reputação da empresa e possibilidade de questionamentos legais, especialmente em cenários que envolvem discriminação ou tratamento desigual. 8. Falta de definição de responsabilidade A utilização de IA introduz um problema recorrente: a indefinição sobre quem responde pelos resultados. Quando uma decisão envolve tecnologia, múltiplos agentes participam do processo, o usuário que solicitou, a área que implementou, o fornecedor da ferramenta e a própria organização. Sem uma política de uso de IA que estabeleça responsabilidades, qualquer falha gera incerteza sobre accountability (responsabilidade), o que dificulta respostas rápidas, gestão de incidentes e defesa jurídica. 9. Desalinhamento com exigências regulatórias O uso corporativo de IA precisa dialogar com um conjunto crescente de normas relacionadas a proteção de dados, segurança da informação e transparência. Sem diretrizes claras, a utilização dessas ferramentas pode violar princípios da LGPD (Lei Geral de Proteção de Dados), especialmente em relação a tratamento de dados pessoais, finalidade e transparência. Além disso, como dissemos anteriormente, regulações específicas sobre inteligência artificial estão em discussão no Brasil e já avançam em outras jurisdições, o que amplia o risco de não conformidade para organizações que não estruturam governança desde agora. 10. Dependência tecnológica sem estratégia A adoção fragmentada de ferramentas de IA cria um cenário de dependência tecnológica sem planejamento. Diferentes soluções são incorporadas sem integração, sem padronização e sem critérios de longo prazo. Isso dificulta a gestão do ambiente, aumenta custos operacionais e limita a capacidade de evolução da arquitetura de TI. A dependência de fornecedores específicos também pode restringir a autonomia da organização, especialmente em contextos que exigem controle sobre dados, modelos e processos. Resumo dos principais riscos da inteligência artificial para empresas Riscos Grau de impacto Uso de dados sensíveis em ferramentas públicas Alto Falta de rastreabilidade nas decisões Alto Dependência de respostas não verificadas Alto Shadow IT Alto Exposição a riscos de segurança da informação Alto Decisões automatizadas sem supervisão adequada Alto Viés algorítmico Médio Falta de definição de responsabilidade Alto Desalinhamento com exigências regulatórias Alto Dependência tecnológica sem estratégica Médio Riscos éticos e jurídicos da inteligência artificial nas empresas Se os riscos operacionais mostram como a IA afeta processos e segurança, os riscos éticos e jurídicos expõem um ponto ainda mais sensível – a capacidade da empresa de sustentar e responder pelas decisões que envolvem inteligência artificial. Ao incorporar IA em fluxos internos, a área de TI assume um papel que ultrapassa a gestão de infraestrutura e passa a influenciar, ainda que indiretamente, decisões com efeitos legais, regulatórios e reputacionais. Esse cenário já se reflete no ambiente regulatório. Iniciativas como o AI Act, na Europa, e projetos de lei em discussão no Brasil indicam uma direção clara: sistemas de IA começam a ser avaliados também sob critérios de transparência, segurança e responsabilidade. À medida que essas ferramentas influenciam análises, recomendações e decisões, aumenta a necessidade de garantir que os resultados possam ser compreendidos, justificados e auditados. Sem esse cuidado, surgem situações como: Para profissionais e gestores de TI, esse contexto traz implicações diretas. A arquitetura tecnológica, as integrações realizadas e as ferramentas autorizadas passam a determinar não apenas a eficiência operacional, mas também o nível de exposição da organização a riscos éticos e jurídicos. Isso exige a definição de critérios que permitam utilizar IA com previsibilidade, rastreabilidade e responsabilidade. Nesse contexto, transparência, explicabilidade e accountability (responsabilidade) integram requisitos técnicos e operacionais. A discussão sobre ética em IA, portanto, se conecta à forma como a organização estrutura sua governança, define limites de uso e estabelece mecanismos de controle, fatores determinantes para um uso seguro e sustentável da tecnologia. Como estruturar uma política de uso de IA na prática A análise dos riscos operacionais, éticos e jurídicos evidencia um ponto comum – a ausência de critérios formais para orientar o uso da inteligência artificial dentro das organizações. Diante desse cenário, a definição de uma política de uso de IA não deve ser tratada como um documento acessório, mas como parte integrante da governança tecnológica e da estratégia de gestão de riscos. Na prática, essa política funciona como um instrumento que estabelece limites, responsabilidades e diretrizes para o uso da IA, alinhando inovação com segurança, conformidade e previsibilidade operacional. Para que seja efetiva, a política precisa partir de um mapeamento claro – onde a IA está sendo utilizada, por quem e com qual finalidade. Sem esse diagnóstico, qualquer tentativa de controle tende a ser incompleta. A partir disso, alguns elementos se tornam indispensáveis. Elementos essenciais de uma política de uso de IA Uma política bem estruturada deve contemplar, no mínimo: Estabelecer quais tipos de dados podem ser utilizados e em quais contextos a IA pode ser aplicada, com atenção especial a informações sensíveis ou estratégicas. Determinar quando a revisão humana é obrigatória, especialmente em processos que envolvem tomada de decisão ou comunicação externa. Definir critérios para utilização de plataformas públicas ou de terceiros, reduzindo riscos associados a shadow IT e exposição de dados. Formalizar quem responde pelo uso da IA em cada contexto, evitando lacunas em situações de falha ou incidente. Garantir que o uso de IA esteja alinhado a frameworks já adotados, como práticas relacionadas à ISO/IEC 27001. Orientar colaboradores sobre riscos, limites e boas práticas, reduzindo o uso inadequado por desconhecimento. Mais do que restringir o uso, essa estrutura permite que a IA seja incorporada de forma controlada, com clareza sobre seus limites e impactos. Dessa forma, há a redução de exposições e cria um ambiente em que a tecnologia pode ser utilizada com maior segurança e consistência. Ao mesmo tempo, evidencia um ponto importante: a governança de IA depende não apenas de tecnologia, mas de conhecimento aplicado. É nesse contexto que a capacitação de equipes ganha relevância, especialmente para profissionais responsáveis por segurança da informação, compliance e gestão de TI. 6 soluções de inteligências artificial nas empresas para acompanhar de perto A definição de uma política de uso de IA estabelece limites e responsabilidades. No entanto, a governança só se consolida quando a organização também adota critérios claros para avaliar as ferramentas que pretende utilizar. Isso ocorre porque a escolha de soluções de IA impacta diretamente todos os riscos discutidos anteriormente, desde exposição de dados até dependência tecnológica e conformidade regulatória. Atualmente, diferentes ferramentas oferecem níveis distintos de controle, transparência e integração com ambientes corporativos. Sem critérios definidos, a adoção tende a ocorrer por conveniência ou popularidade, o que amplia o risco de decisões desalinhadas com a estratégia da empresa. Por esse motivo, acompanhar o mercado de IA não significa apenas conhecer novas soluções, mas entender como cada uma delas se encaixa, ou não, nos requisitos de governança, segurança e compliance. Veja abaixo 6 soluções de IA para empresas acompanharem de perto Algumas plataformas têm se destacado no uso corporativo, seja pela capacidade técnica, seja pela evolução de recursos voltados à governança. 1. Databricks Mosaic AI Integrada ao ecossistema de dados da Databricks, a Mosaic AI permite desenvolver, treinar e implantar modelos diretamente sobre pipelines de dados corporativos. O diferencial está na governança nativa: controle de dados, versionamento e integração com lakehouses. É uma abordagem que aproxima IA da engenharia de dados e reduz o uso disperso de ferramentas externas. 2. Snowflake Cortex Inserida dentro da plataforma de dados da Snowflake, a Cortex permite aplicar modelos de IA diretamente sobre dados armazenados no data cloud, sem necessidade de movimentação para ambientes externos. Isso reduz riscos associados à transferência de dados e facilita o controle de acesso, um ponto crítico para governança de IA. 3. AWS Bedrock Serviço da Amazon que permite acessar e orquestrar múltiplos modelos de IA generativa com controle sobre dados e integração com serviços da nuvem AWS. O foco está em permitir uso corporativo com camadas de segurança, isolamento e governança mais robustas do que ferramentas públicas abertas. 4. ChatGPT (OpenAI) Amplamente utilizado em atividades como geração de conteúdo, apoio a análises e automação de tarefas cognitivas. Em ambientes corporativos, versões com maior controle de dados e gestão de usuários ganham relevância, especialmente para reduzir riscos associados ao uso indiscriminado. 5. Claude (Anthropic) Posicionado com foco em segurança e alinhamento de respostas, apresenta abordagens voltadas à redução de riscos em outputs. É frequentemente considerado em cenários que exigem maior previsibilidade e controle sobre o comportamento do modelo. 6. Microsoft Copilot (integração com Microsoft 365 e Azure) Destaca-se pela integração com ferramentas já utilizadas no ambiente corporativo. Permite incorporar IA em fluxos de trabalho existentes, com maior aderência a políticas de segurança e governança já implementadas pela organização. A análise dessas soluções não deve se limitar à funcionalidade. Para profissionais de TI e gestores, alguns critérios precisam orientar a decisão: Esse tipo de avaliação conecta diretamente a escolha tecnológica à governança de IA. Ou seja, a decisão sobre qual ferramenta utilizar passa a ser, também, uma decisão sobre risco, conformidade e sustentabilidade operacional. Governança de IA como prática contínua: o próximo passo para empresas e gestores A análise dos riscos, das implicações éticas e das decisões tecnológicas evidencia um ponto comum – o uso de inteligência artificial já faz parte da operação, mas nem sempre está acompanhado de critérios estruturados. Nesse cenário, a governança de IA não se resume à criação de um documento ou à definição de regras pontuais. Ela envolve a construção de um modelo contínuo, capaz de acompanhar a evolução das ferramentas, adaptar-se a novos riscos e orientar decisões técnicas com base em segurança, conformidade e responsabilidade. Por isso, profissionais e gestores que atuam com tecnologia precisam lidar com questões que combinam arquitetura de sistemas, proteção de dados, avaliação de riscos e interpretação regulatória. A ausência desse preparo limita a capacidade da organização de utilizar IA com segurança e consistência. Ao mesmo tempo, organizações que estruturam governança conseguem avançar com maior controle, reduzindo exposição e criando condições para uso estratégico da tecnologia. Nesse ponto, a capacitação faz parte da própria estratégia de TI. Para equipes que precisam lidar com esses desafios na prática, a formação em governança de IA oferece um caminho estruturado para compreender: A Escola Superior de Redes oferece a formação Governança de IA para todos e outros cursos correlatos, desenvolvidos para profissionais que atuam diretamente com tecnologia, segurança da informação e gestão. O primeiro curso aborda desde os fundamentos até a aplicação prática da governança, conectando o uso da IA às exigências reais do ambiente corporativo. Se a sua empresa já utiliza inteligência artificial, mesmo que de forma distribuída, este é o momento de estruturar esse uso com critérios claros. 👉 Conheça a formação e prepare sua equipe para atuar com IA de forma segura, rastreável e alinhada às exigências atuais. Quero conhecer melhor a formação de governança de IA da ESR Perguntas frequentes sobre sobre IA nas empresas 1. O  que é governança de IA e por que ela é importante? Governança de IA é o conjunto de diretrizes, controles e responsabilidades que orientam o uso da inteligência artificial dentro da organização. Ela é importante porque define como a tecnologia pode ser utilizada com segurança, previsibilidade e conformidade, reduzindo riscos operacionais, jurídicos e reputacionais. 2. Quais são os principais riscos da inteligência artificial para empresas? Os principais riscos incluem uso indevido de dados sensíveis, falta de rastreabilidade nas decisões, respostas incorretas não verificadas, exposição a falhas de segurança, conflitos regulatórios e ausência de definição de responsabilidade. Esses riscos aumentam quando a IA é adotada sem critérios claros de uso e controle. 3. O uso de IA pode violar a LGPD? Sim, especialmente quando envolve tratamento inadequado de dados sensíveis. Isso pode ocorrer, por exemplo, quando informações são inseridas em ferramentas externas sem controle, quando não há transparência sobre o uso dos dados ou quando decisões automatizadas afetam titulares sem critérios claros. 4. O que é Shadow IT em inteligência artificial? Shadow IT em IA ocorre quando colaboradores utilizam ferramentas de inteligência artificial sem conhecimento ou aprovação da área de TI. Esse comportamento reduz a visibilidade sobre o uso da tecnologia, dificulta o controle de dados e pode gerar riscos de segurança e compliance. 5. Minha empresa precisa de uma política de uso de IA? Sim. A política de uso de IA estabelece regras claras sobre como a tecnologia pode ser utilizada, quais dados podem ser processados, quem é responsável pelos resultados e quais controles devem ser aplicados. Sem essa definição, o uso tende a ocorrer de forma desestruturada. 6. Quem deve ser responsável pelo uso de IA na empresa? A responsabilidade deve ser formalmente definida pela organização. Normalmente envolve uma combinação entre áreas de TI, segurança da informação, compliance e as áreas de negócio que utilizam a tecnologia. O importante é que exista clareza sobre accountability em caso de falhas ou incidentes. 7. Como começar a implementar governança de IA? O primeiro passo é mapear onde e como a IA está sendo utilizada na empresa. Em seguida, é necessário definir diretrizes de uso, critérios de segurança, responsabilidades e processos de validação. A capacitação das equipes também é essencial para garantir aplicação prática dessas diretrizes. 8. A governança de IA é só para grandes empresas? Não. Empresas de todos os portes utilizam IA, mesmo que de forma indireta. Quanto mais cedo a governança for estruturada, menor o risco de exposição e maior a capacidade de usar a tecnologia de forma estratégica. Quero conhecer melhor a formação de governança de IA da ESR

A Criptografia Pós-Quântica (PQC) descreve um conjunto de técnicas criptográficas desenvolvidas para proteger dados de ataques executados por computadores quânticos, utilizando algoritmos resistentes à capacidade computacional esperada dessa nova geração de máquinas. O tema é estratégico porque boa parte da infraestrutura digital moderna ainda depende de algoritmos de criptografia assimétrica, como RSA e ECC, amplamente utilizados em certificados digitais, VPNs, assinaturas eletrônicas, autenticação e protocolos de comunicação segura. No entanto, esses modelos apresentam vulnerabilidades conhecidas diante da evolução da computação quântica e segurança, especialmente com o avanço de algoritmos quânticos capazes de resolver operações matemáticas consideradas inviáveis para computadores tradicionais. Embora computadores quânticos capazes de quebrar esses padrões em larga escala ainda não estejam plenamente disponíveis, o risco já existe no presente. Ataques conhecidos como Harvest Now, Decrypt Later (“coletar agora, descriptografar depois”) seguem exatamente essa lógica, na qual informações criptografadas são capturadas hoje para serem descriptografadas futuramente, quando a capacidade computacional quântica atingir maturidade suficiente. O impacto desse cenário é particularmente crítico para organizações que lidam com dados sensíveis e de longo ciclo de vida, como: ●  registros médicos; ●  propriedade intelectual; ●  contratos estratégicos; ●  sistemas financeiros; ●  infraestrutura crítica; ●  informações governamentais sensíveis. Por esse motivo, a ameaça quântica é um dos pilares da resiliência cibernética contemporânea, que compõe a governança de risco tecnológico e a proteção de dados de longo prazo. Ao longo deste conteúdo, vamos analisar: ●  o que é criptografia pós-quântica; ●  por que a transição começou antes do chamado Q-Day; ●  como os novos algoritmos NIST estão sendo estruturados; ●  quais riscos os modelos criptográficos atuais já enfrentam; ●  por que a agilidade criptográfica se tornou prioridade para estratégias modernas de segurança da informação. Este artigo integra o cluster de conteúdos sobre computação quântica da ESR e aprofunda a discussão iniciada no conteúdo sobre computação quântica e criptografia e seus impactos na segurança digital.  Veja também: Quais são os três padrões da criptografia pós-quântica?Computação quântica e cibersegurança: o que muda na proteção de dados O que é o Q-Day e por que ele preocupa a segurança digital? O termo Q-Day é utilizado para descrever o momento em que computadores quânticos terão capacidade prática de quebrar algoritmos criptográficos amplamente utilizados atualmente. A segurança digital moderna depende da dificuldade matemática de resolver determinados problemas computacionais, como o RSA, baseado na fatoração de números primos extremamente grandes, e a Criptografia de Curva Elíptica (ECC), sustentada pela complexidade matemática de operações sobre curvas elípticas. Em computadores clássicos, essas operações exigiriam um tempo computacional inviável, limitação técnica sobre a qual a criptografia assimétrica contemporânea foi construída. A computação quântica modifica essa lógica ao operar com princípios diferentes da computação tradicional. Algoritmos quânticos, como o algoritmo de Shor, conseguem resolver determinados problemas matemáticos de forma exponencialmente mais eficiente. Em termos práticos, isso significa que mecanismos considerados seguros hoje poderão apresentar vulnerabilidades quando a capacidade computacional quântica atingir sua maturidade operacional. Esse cenário afeta diretamente as tecnologias utilizadas diariamente em ambientes corporativos e governamentais, incluindo: ●  certificados digitais; ●  autenticação multifator; ●  VPNs; ●  assinaturas eletrônicas; ●  infraestrutura PKI; ●  protocolos TLS; ●  transações financeiras; ●  comunicações críticas. Por esse motivo, a discussão sobre computação quântica e segurança aborda continuidade operacional, proteção de dados sensíveis e governança de risco tecnológico. A questão mais sensível, porém, envolve a relação entre tempo e confidencialidade da informação. Muitos dados precisam permanecer protegidos durante décadas. Informações médicas, registros governamentais, propriedade intelectual, contratos estratégicos e sistemas de defesa possuem valor permanente ou de longo prazo. Nesse contexto, a preocupação não está restrita ao momento em que o Q-Day ocorrerá, mas à exposição acumulada até lá. É desse desafio que surge o conceito de Harvest Now, Decrypt Later, considerado um dos principais aceleradores da transição para a criptografia pós-quântica. O que é a ameaça Harvest Now, Decrypt Later O modelo Harvest Now, Decrypt Later parte de uma lógica relativamente simples: coletar hoje informações criptografadas para descriptografá-las futuramente, quando houver capacidade computacional suficiente para quebrar os algoritmos atuais. Isso significa que um dado protegido hoje não está necessariamente seguro no longo prazo. Mesmo sem capacidade imediata de descriptografia, agentes maliciosos podem armazenar grandes volumes de informação e aguardar a maturidade operacional da computação quântica. Essa dinâmica altera a forma como a segurança da informação é analisada. Historicamente, a proteção criptográfica era avaliada considerando as ameaças contemporâneas. Com o avanço da ameaça quântica, o horizonte de risco se expande para dados que continuarão sensíveis muitos anos depois da coleta. O valor temporal da informação assume papel central dentro da estratégia de proteção digital. Quanto maior a necessidade de confidencialidade prolongada, maior tende a ser a exposição associada à permanência em algoritmos vulneráveis, especialmente em estruturas que ainda dependem exclusivamente de RSA e ECC. Esse cenário afeta diretamente setores como: ●  saúde; ●  defesa; ●  sistema financeiro; ●  infraestrutura crítica; ●  telecomunicações; ●  pesquisa científica; ●      administração pública. Em muitos desses ambientes, o ciclo de vida da informação ultrapassa 10 ou 20 anos. Registros médicos, documentos estratégicos, dados governamentais sensíveis e propriedade intelectual precisam manter a confidencialidade durante períodos muito superiores ao tempo médio de atualização da infraestrutura tecnológica. Por esse motivo, a transição para modelos de segurança pós-quântica não pode ser tratada como uma atualização pontual de software ou hardware. A discussão envolve governança, continuidade operacional e planejamento de longo prazo para a proteção de dados sensíveis. Essa preocupação acelerou o desenvolvimento dos novos algoritmos NIST PQC, uma das principais referências internacionais para a transição criptográfica. Os novos padrões do NIST e a corrida pela segurança pós-quântica A necessidade de substituir algoritmos vulneráveis à computação quântica levou o  National Institute of Standards and Technology (NIST) a conduzir um dos projetos de padronização criptográfica mais relevantes das últimas décadas. O objetivo era selecionar algoritmos capazes de preservar a confidencialidade, a autenticação e a integridade mesmo diante da evolução da capacidade computacional quântica. O processo começou em 2016 e reuniu pesquisadores, universidades, empresas de tecnologia e especialistas em segurança da informação de diferentes países. Durante anos, os algoritmos candidatos foram submetidos a auditorias públicas, testes de desempenho, análises matemáticas e avaliações de interoperabilidade. A validação não estava restrita à resistência criptográfica. Os novos padrões precisavam operar em ambientes reais, com limitações de processamento, consumo de memória, escalabilidade e compatibilidade com infraestruturas já existentes. Diante disso, entre os algoritmos selecionados pelo NIST, alguns se tornaram centrais para a transição da criptografia pós-quântica. 1. H3 ML-KEM – proteção para a troca de chaves criptográficas O ML-KEM, baseado no CRYSTALS-Kyber, foi selecionado como padrão para encapsulamento e troca de chaves criptográficas. Sua função é proteger a comunicação entre sistemas, impedindo que terceiros interceptem ou reconstruam chaves utilizadas em conexões seguras. Esse algoritmo ocupa posição estratégica porque operações de troca de chaves sustentam protocolos utilizados diariamente em VPNs, TLS, aplicações corporativas e serviços digitais. O modelo foi desenvolvido para equilibrar: ●  a resistência a ataques quânticos; ●  o desempenho computacional; ●  a eficiência operacional; ●  a viabilidade de implementação em larga escala. 2. H3 ML-DSA e a proteção das assinaturas digitais Outro ponto crítico da transição criptográfica envolve assinaturas digitais. O ML-DSA, derivado do CRYSTALS-Dilithium, foi escolhido pelo NIST para garantir a autenticidade e a integridade em ambientes sujeitos à ameaça quântica. Na prática, esse algoritmo protege mecanismos utilizados em: ●  autenticação; ●  certificados digitais; ●  assinatura de documentos; ●  validação de software; ●  identidade digital. A escolha do NIST sinaliza uma mudança importante na arquitetura da confiança digital contemporânea. Isso ocorre porque assinaturas digitais sustentam boa parte das operações eletrônicas modernas, desde transações financeiras até infraestrutura governamental. 3. H3 SLH-DSA e a segurança baseada em funções hash O SLH-DSA, derivado do SPHINCS+, também foi padronizado pelo NIST para aplicações de assinatura digital resistentes à computação quântica. Diferentemente do ML-DSA, que é baseado em criptografia de reticulados (lattices), o SLH-DSA utiliza uma abordagem fundamentada em funções hash, tecnologia amplamente estudada e considerada uma das bases mais consolidadas da criptografia moderna. Sua principal função é oferecer uma alternativa criptográfica para cenários que exigem diversidade de mecanismos de segurança e redução de dependência de uma única família matemática. Embora apresente assinaturas maiores e menor eficiência operacional em alguns contextos, o algoritmo amplia as opções disponíveis para organizações que planejam estratégias de transição para a criptografia pós-quântica. Segurança pós-quântica exige agilidade criptográfica A adoção desses padrões não significa uma migração imediata e simples. Ambientes corporativos frequentemente operam com sistemas legados, aplicações distribuídas, dispositivos IoT, múltiplos fornecedores e arquiteturas híbridas. Em muitos casos, algoritmos criptográficos estão profundamente incorporados à infraestrutura. Por isso, não devemos nos concentrar apenas em “qual algoritmo substituirá o RSA”. A prioridade deve ser a construção de agilidade criptográfica, ou seja, a capacidade de adaptar rapidamente mecanismos criptográficos sem comprometer a operação, a interoperabilidade ou a continuidade dos serviços. Esse conceito é importante uma vez que a transição para a segurança pós-quântica não ocorrerá em uma única etapa. Organizações precisarão conviver durante anos com modelos híbridos, que combinem algoritmos tradicionais e algoritmos resistentes a computadores quânticos dentro da mesma infraestrutura. Nesse cenário, inventariar dependências criptográficas, classificar riscos e iniciar testes controlados se tornou parte das estratégias modernas de resiliência cibernética. Como iniciar a transição para a criptografia pós-quântica? A migração para modelos de criptografia pós-quântica não começa pela substituição imediata de algoritmos. O primeiro desafio está em identificar em quais pontos a criptografia já existe dentro da operação. Em muitas organizações, mecanismos criptográficos estão distribuídos entre aplicações legadas, VPNs, certificados digitais, APIs, sistemas de autenticação, dispositivos IoT, bancos de dados e integrações entre ambientes cloud. Parte dessas dependências sequer possui documentação atualizada. Por esse motivo, a transição para modelos de segurança pós-quântica exige uma abordagem baseada em visibilidade, classificação de risco e interoperabilidade. 1) Inventário criptográfico como ponto de partida técnico O primeiro movimento envolve mapear quais sistemas utilizam a criptografia assimétrica e quais algoritmos sustentam essas operações. No dia a dia da organização, isso significa identificar: ●  em que partes RSA e ECC estão implementados; ●  quais aplicações dependem de PKI; ●  quais certificados possuem ciclos longos de renovação; ●  quais integrações utilizam troca de chaves criptográficas; ●  quais ambientes armazenam dados sensíveis de longo prazo. Esse inventário também precisa considerar as dependências indiretas. Muitas aplicações utilizam bibliotecas criptográficas incorporadas por fornecedores terceiros, o que amplia a complexidade da migração criptográfica. Sem essa visibilidade, qualquer estratégia de atualização tende a gerar incompatibilidades operacionais e aumento de superfície de risco. 2) O valor temporal da informação muda a prioridade da migração Nem todo dado exige o mesmo nível de proteção temporal. Informações transitórias possuem impacto limitado caso sejam descriptografadas futuramente. Já dados estratégicos mantêm relevância operacional, jurídica ou financeira durante décadas, fator que transforma completamente a priorização da transição. Ambientes associados a propriedade intelectual, contratos de longo prazo, infraestrutura crítica, registros médicos, pesquisa científica, sistemas governamentais, defesa e telecomunicação costumam exigir ciclos de confidencialidade muito superiores ao tempo médio de renovação tecnológica. É aqui que o modelo Harvest Now, Decrypt Later ganha dimensão prática dentro da governança de risco tecnológico: os ataques contemporâneos somam-se à exposição acumulada de informações que continuarão valiosas no futuro. 3) Interoperabilidade e ambientes híbridos A adoção dos novos algoritmos NIST PQC ocorrerá gradualmente. Durante anos, as organizações precisarão operar em ambientes híbridos, combinando algoritmos tradicionais e algoritmos resistentes a computadores quânticos dentro da mesma infraestrutura. Esse cenário cria desafios importantes de interoperabilidade. Protocolos, aplicações, dispositivos de rede e sistemas legados precisarão manter a compatibilidade sem comprometer o desempenho, a estabilidade ou a autenticação. Por esse motivo, testes controlados começam a ocupar um papel relevante na preparação técnica para a era pós-quântica. O objetivo deve ser não só validar a segurança matemática, mas analisar: ●  o impacto operacional; ●  o consumo computacional; ●  a compatibilidade entre sistemas; ●  o desempenho em ambientes distribuídos; ●  o comportamento de aplicações críticas. A construção dessa capacidade técnica tende a diferenciar organizações preparadas para lidar com a próxima transição criptográfica daquelas que ainda operam exclusivamente sob modelos concebidos para ameaças anteriores. Resumo visual: criptografia tradicional vs. criptografia pós-quântica Aspecto Criptografia tradicional Criptografia pós-quântica Base matemática    Fatoração e curvas elípticas Problemas matemáticos resistentes a quantum Principais algoritmos RSA e ECC ML-KEM, ML-DSA, SLH-DSA Resistência a computadores quânticos Vulnerável Projetada para resistência quântica Cenário de risco     Ataques clássicos Ataques clássicos e quânticos Dependência atual Amplamente utilizada Processo gradual de adoção Objetivo estratégico Segurança contemporânea Proteção de longo prazo Desafio operacional Atualização convencional Agilidade criptográfica e interoperabilidade A transição criptográfica começou antes da ruptura A preparação para a criptografia pós-quântica não está relacionada apenas com a chegada de computadores quânticos plenamente operacionais. O movimento atual surge da combinação entre exposição prolongada de dados, dependência estrutural de algoritmos vulneráveis e necessidade de proteção de informações que continuarão sensíveis nas próximas décadas. Por esse motivo, a transição para modelos de segurança pós-quântica é tratada como um processo contínuo de adaptação arquitetural, e não como uma simples substituição técnica de algoritmos. A adoção dos novos algoritmos NIST PQC, o desenvolvimento de estratégias de agilidade criptográfica e a construção de ambientes preparados para interoperabilidade entre modelos tradicionais e algoritmos resistentes a computadores quânticos fazem parte da evolução natural da segurança digital contemporânea. Ao mesmo tempo, as organizações que iniciam agora processos de inventário criptográfico, classificação de dados sensíveis e testes controlados de interoperabilidade tendem a construir vantagem operacional diante de uma das maiores mudanças já enfrentadas pela infraestrutura de segurança da informação. Nesse cenário, compreender a relação entre computação quântica e criptografia não é um diferencial restrito à pesquisa acadêmica. É preciso levar o conhecimento para compor decisões práticas de arquitetura, governança e continuidade operacional. O futuro da segurança digital começa pela capacidade de se interpretarem riscos tecnológicos antes que eles se tornem incidentes concretos. Sua infraestrutura está preparada para a era quântica? A transição para modelos de segurança da informação quântica exige profissionais capazes de interpretar riscos emergentes, avaliar impactos operacionais e estruturar ambientes resilientes diante da evolução tecnológica. As formações da ESR aprofundam temas ligados a: ●  resiliência cibernética; ●  governança de risco tecnológico; ●  segurança de redes; ●  interoperabilidade criptográfica; ●  proteção de dados sensíveis; ●  arquiteturas seguras para ambientes distribuídos. Conheça as formações da ESR voltadas para segurança, redes e gestão de riscos tecnológicos. Quero conhecer a ementa da melhor formação  do Brasil em Gestão de Risco e Segurança de Redes FAQ – Perguntas frequentes sobre criptografia pós-quântica 1) O que é criptografia pós-quântica? A criptografia pós-quântica reúne algoritmos desenvolvidos para resistir a ataques executados por computadores quânticos, protegendo dados de vulnerabilidades previstas para modelos criptográficos atuais. 2) O que significa Q-Day? O Q-Day representa o momento em que computadores quânticos terão capacidade prática de quebrar algoritmos criptográficos amplamente utilizados atualmente, como RSA e ECC. 3) O que é o ataque Harvest Now, Decrypt Later? É uma estratégia em que informações criptografadas são coletadas hoje para serem descriptografadas futuramente, quando houver capacidade computacional suficiente para quebrar os algoritmos atuais. 4) Quais algoritmos estão sendo substituídos? Os principais modelos sob risco são RSA e ECC, utilizados em certificados digitais, VPNs, autenticação, assinaturas eletrônicas e protocolos de comunicação segura. 5) O que são ML-KEM e ML-DSA? São algoritmos selecionados pelo NIST como parte dos novos padrões de segurança pós-quântica. O ML-KEM é voltado para a troca de chaves criptográficas, enquanto o ML-DSA protege assinaturas digitais. 6) A computação quântica já representa um risco real? Sim. Embora computadores quânticos capazes de quebrar criptografia em larga escala ainda estejam em evolução, dados capturados atualmente podem ser armazenados para descriptografia futura. 7) O que é agilidade criptográfica? É a capacidade de adaptar rapidamente mecanismos criptográficos dentro da infraestrutura sem comprometer a continuidade operacional, a compatibilidade entre sistemas ou a segurança. 8) A criptografia pós-quântica substitui imediatamente os modelos atuais? Não. A transição será gradual e envolverá ambientes híbridos, combinando algoritmos tradicionais e algoritmos resistentes a computadores quânticos durante muitos anos. Quero conhecer a formação da ESR

A transição de carreira para TI costuma ser menos difícil do que escolher por onde começar. Quem está chegando ao setor pela primeira vez rapidamente encontra uma quantidade enorme de caminhos possíveis. Redes de computadores, computação em nuvem, cibersegurança, DevOps, dados, infraestrutura, gestão, compliance, governança. Em poucos dias de pesquisa, surgem dezenas de siglas, certificações e recomendações diferentes. A sensação é conhecida por muitos profissionais que vêm de áreas como Administração, Engenharia, Logística, Atendimento, Finanças ou mesmo por estudantes que ainda buscam uma direção profissional. Quanto mais conteúdos consomem, menos clareza parecem ter sobre qual caminho seguir. Essa dúvida é compreensível. A tecnologia não funciona como uma profissão única. Ela é formada por diversas especialidades, cada uma exigindo conhecimentos, rotinas e perfis comportamentais diferentes. Por isso, a pergunta mais importante para quem está iniciando não é qual área paga mais ou qual certificação está em alta. A decisão que costuma gerar melhores resultados é identificar uma trilha compatível com a forma como você gosta de trabalhar, resolver problemas e aprender. Neste artigo, vamos analisar quatro das principais trilhas profissionais da área de tecnologia: ●      Redes de computadores; ●      Computação em nuvem; ●      Cibersegurança; ●      Gestão de TI. Ao final, você terá uma visão mais clara sobre por onde começar na TI e qual caminho faz sentido para sua realidade profissional. 💡Você também pode gostar – Computação quântica: o que podemos esperar dessa tecnologia e quais suas tendências? Como está o mercado de TI em 2026? Se você pensa em fazer uma transição de carreira para TI em 2026 é possível que se depare com um cenário contraditório. No entanto, isso ocorre apenas para quem acompanha as notícias do setor à primeira vista. Nos últimos anos, empresas de tecnologia realizaram reestruturações relevantes em diferentes partes do mundo. A  Atlassian anunciou cortes que impactaram aproximadamente 1.600 profissionais, enquanto a Epic Games realizou novas rodadas de desligamentos após já ter reduzido parte de sua força de trabalho em anos anteriores. Esses números podem transmitir a impressão de que o mercado perdeu força. Os dados, porém, mostram uma realidade mais complexa. Grande parte dessas movimentações esteve relacionada com ajustes de crescimento acelerado realizados durante o período pós-pandemia, mudanças de estratégia corporativa e reestruturações específicas de determinados negócios, não necessariamente com uma redução da importância da tecnologia dentro das organizações. Enquanto algumas empresas reduziam equipes, outras ampliavam investimentos em áreas consideradas estratégicas para os próximos anos, especialmente computação em nuvem, segurança da informação, inteligência artificial, infraestrutura digital e governança tecnológica. A própria demanda por profissionais de tecnologia especializados em segurança da informação, infraestrutura digital e tecnologias emergentes continua motivando a expansão de operações e contratação de talentos em diversos mercados. Outro movimento relevante envolve a mudança do perfil profissional procurado pelas empresas. Funções de entrada passaram a exigir cada vez mais competências técnicas e comportamentais que antes eram associadas a cargos mais experientes. Para quem pretende migrar para tecnologia, isso traz uma conclusão importante. O mercado continua oferecendo oportunidades, mas a lógica de entrada ficou mais seletiva. Em vez de tentar aprender todas as tecnologias disponíveis, profissionais que constroem uma base sólida em uma área específica tendem a desenvolver suas carreiras com mais consistência. É justamente por isso que compreender as diferentes áreas da tecnologia se tornou uma etapa importante para quem deseja fazer uma transição de carreira para TI e ingressar no mercado de TI com mais direcionamento. Redes de Computadores: a fundação sobre a qual a tecnologia funciona Quando alguém acessa um sistema corporativo, envia um e-mail, participa de uma videoconferência ou utiliza uma aplicação em nuvem, existe uma infraestrutura que permite que essas informações circulem entre dispositivos, servidores e usuários. Essa infraestrutura é construída sobre Redes de Computadores. Embora muitas vezes seja menos visível para quem está fora da área, Redes continua sendo uma das bases mais importantes da tecnologia moderna. Afinal, nenhuma aplicação funciona isoladamente. Dados precisam trafegar, dispositivos precisam se comunicar e sistemas precisam permanecer disponíveis. Por isso, profissionais de Redes atuam planejando, implementando, monitorando e solucionando problemas relacionados com a conectividade dos ambientes corporativos. Mais do que configurar equipamentos, a área exige compreensão sobre como a informação percorre toda a infraestrutura tecnológica. Qual perfil costuma encontrar afinidade com Redes? Redes costuma atrair profissionais que: ●      Gostam de lógica; ●      Têm perfil investigativo; ●      Apreciam resolver problemas técnicos; ●      Possuem atenção aos detalhes; ●      Sentem-se confortáveis trabalhando com estruturas e processos. Muitos profissionais oriundos de Engenharia, áreas técnicas e suporte costumam encontrar bastante afinidade com essa trilha. Por que Redes é uma boa porta de entrada? Uma das principais vantagens dessa área está na formação de base. Quem compreende conceitos de roteamento, protocolos, segmentação, infraestrutura e comunicação entre sistemas costuma desenvolver com mais facilidade conhecimentos em Cloud Computing, Segurança da Informação e Arquitetura de Soluções. Em outras palavras, Redes ajuda a construir uma visão ampla do funcionamento da tecnologia antes da especialização. Para quem deseja trabalhar com Redes, essa base é relevante mesmo quando a carreira evolui para outras especializações. Computação em Nuvem: uma das áreas com a maior demanda por profissionais qualificados Durante décadas, empresas investiram em servidores físicos situados dentro de suas próprias instalações. Hoje, uma parcela significativa dessas operações está distribuída em plataformas como AWS, Azure e Google Cloud. Essa transformação criou uma demanda crescente por profissionais capazes de projetar, operar e otimizar ambientes em nuvem. A computação em nuvem se tornou parte da rotina de empresas de praticamente todos os segmentos, desde startups até instituições financeiras, órgãos públicos e grandes indústrias. O que faz um profissional de Cloud? A atuação envolve atividades como: ●      Provisionamento de ambientes; ●      Automação de infraestrutura; ●      Gerenciamento de recursos; ●      Otimização de custos; ●      Disponibilidade de sistemas; ●      Integração entre serviços. O objetivo é garantir que aplicações e operações permaneçam eficientes, escaláveis e disponíveis. Qual perfil costuma encontrar afinidade com Cloud? A área costuma atrair profissionais que: ●      Gostam de inovação; ●      Têm interesse por automação; ●      Apreciam ambientes dinâmicos; ●      Adaptam-se rapidamente a mudanças; ●      Possuem facilidade para aprender novas tecnologias. Por que Cloud chama tanta atenção de quem está migrando para TI? Além da elevada demanda por profissionais especializados, existe uma oferta consolidada de certificações de TI reconhecidas pelo mercado. Para quem pesquisa sobre nuvem AWS iniciante, certificações introdutórias costumam funcionar como uma porta de entrada estruturada para compreender os fundamentos da área e desenvolver uma base sólida de conhecimento. Certificações como AWS Cloud Practitioner frequentemente aparecem como um primeiro passo para quem deseja desenvolver conhecimentos em computação em nuvem e construir experiência profissional na área. 💡Você também pode gostar – Adoção de redes Wi-Fi 6 e 7: o que está por trás dessas tecnologias? Cibersegurança: proteger organizações em um ambiente de ameaças permanentes O crescimento dos ataques digitais transformou a Segurança da Informação em uma preocupação estratégica para empresas, governos e instituições de todos os portes. À medida que organizações ampliam sua presença digital, cresce também a necessidade de profissionais capazes de proteger sistemas, dados e operações. Por isso, a Cibersegurança se consolidou como uma das áreas mais relevantes da tecnologia contemporânea. Ao contrário da percepção popular, a área não se resume a atividades ofensivas ou testes de invasão. A proteção digital envolve uma combinação de processos, tecnologias, pessoas e governança capazes de reduzir riscos e fortalecer a resiliência das organizações. Esse cenário ajuda a explicar por que as carreiras em Cibersegurança continuam atraindo profissionais de diferentes formações e níveis de experiência. O que faz um profissional de Cibersegurança? A resposta depende bastante da especialização. Existem profissionais atuando com: ●      Gestão de riscos; ●      Governança; ●      Conformidade regulatória; ●      Monitoramento de ameaças; ●      Resposta a incidentes; ●      Arquitetura de segurança; ●      Testes de segurança; ●      Proteção de identidades e acessos. Essa diversidade permite diferentes portas de entrada dentro da própria área. Enquanto alguns profissionais trabalham diretamente com tecnologias de proteção, outros atuam em funções relacionadas com auditoria, compliance, governança e gestão de riscos. Que características são comuns entre os profissionais de Segurança? Normalmente são pessoas que: ●      Possuem curiosidade natural; ●      Gostam de investigação; ●      Têm perfil analítico; ●      Observam padrões e comportamentos; ●      Demonstram interesse por riscos e conformidade. A capacidade de compreender cenários complexos e identificar potenciais vulnerabilidades costuma ser tão importante quanto o conhecimento técnico. Por que tanta gente considera migrar para Segurança? Além da relevância estratégica para as organizações, trata-se de uma área que mantém demanda consistente mesmo em períodos de instabilidade econômica. Independentemente do setor de atuação, proteger ativos digitais continua sendo uma necessidade permanente. Outro fator importante é que a expansão da transformação digital ampliou significativamente a superfície de ataque das organizações. Ambientes em nuvem, trabalho remoto, dispositivos móveis, APIs e aplicações conectadas aumentaram a necessidade de profissionais preparados para lidar com ameaças cada vez mais sofisticadas. Por isso, a área de Cibersegurança permanece entre as mais observadas por quem busca construir uma carreira em tecnologia com forte perspectiva de crescimento. Gestão de TI: a conexão entre tecnologia, pessoas e resultados Nem toda carreira em tecnologia exige atuação profundamente técnica. À medida que as organizações se tornam mais dependentes de tecnologia, cresce a necessidade de profissionais capazes de coordenar equipes, estruturar processos e alinhar investimentos tecnológicos aos objetivos do negócio. É justamente nesse ponto que surge a Gestão de TI. A área funciona como uma ponte entre as necessidades da organização e as equipes responsáveis pela execução técnica. Mais do que administrar ferramentas, esses profissionais ajudam a transformar tecnologia em resultados concretos para a empresa. O que faz um profissional de Gestão de TI? Entre suas atribuições podem estar: ●      Gestão de serviços; ●      Gerenciamento de projetos; ●      Governança de TI; ●      Planejamento estratégico; ●      Liderança de equipes; ●      Gestão de fornecedores; ●      Definição de processos. O foco não está apenas na tecnologia em si, mas na geração de valor para a organização. Quem tende a se destacar em Gestão de TI? Essa trilha costuma despertar interesse em profissionais que: ●      Possuem experiência prévia em liderança; ●      Gostam de organização e planejamento; ●      Têm facilidade de comunicação; ●      Conseguem transitar entre diferentes áreas; ●      Possuem visão sistêmica dos negócios. Por essa razão, profissionais vindos de Administração, Engenharia, Logística, Finanças, Recursos Humanos e áreas correlatas frequentemente encontram oportunidades interessantes nesse segmento. Por que essa trilha pode ser interessante para profissionais em transição? Pessoas que já construíram experiências em liderança, gestão de equipes ou processos organizacionais costumam chegar à área com competências que continuam relevantes dentro do contexto tecnológico. Nesses casos, o diferencial não está apenas no domínio técnico, mas na capacidade de conectar estratégia, processos e tecnologia. Para quem busca desenvolver uma carreira em Gestão de TI, essa combinação entre conhecimento de negócios e compreensão tecnológica costuma representar um importante diferencial competitivo. Qual trilha combina mais com o seu perfil? Se você se identifica com… Pode encontrar mais aderência em… O que costuma fazer no dia a dia Possíveis evoluções de carreira Lógica, infraestrutura, resolução de problemas técnicos e análise de conectividade Redes de Computadores Configurar, monitorar e manter ambientes de rede, garantindo comunicação entre sistemas e dispositivos Arquitetura de Redes, Cloud Computing, Segurança da Informação, Infraestrutura Automação, inovação tecnológica, escalabilidade e ambientes dinâmicos Computação em Nuvem Administrar serviços em nuvem, automatizar processos e otimizar recursos computacionais Arquiteto Cloud, DevOps, Site Reliability Engineering (SRE), Arquitetura de Soluções Investigação, análise de riscos, proteção de dados e conformidade Cibersegurança        Monitorar ameaças, avaliar vulnerabilidades, gerenciar riscos e fortalecer controles de segurança Segurança Ofensiva, Segurança Defensiva, GRC, Gestão de Identidades e Acessos (IAM), Arquitetura de Segurança Liderança, organização, gestão de processos e relacionamento com diferentes áreas Gestão de TI   Coordenar projetos, equipes, serviços e iniciativas de tecnologia alinhadas aos objetivos do negócio Gerência de TI, Governança de TI, Gestão de Serviços, PMO, CIO   Construir uma base técnica ampla antes de se especializar Redes de Computadores Desenvolver compreensão sobre o funcionamento da infraestrutura tecnológica Cloud, Segurança, Infraestrutura, Arquitetura   Aproveitar a experiência anterior em administração, gestão ou liderança Gestão de TI Aplicar conhecimentos de gestão dentro de ambientes tecnológicos   Governança, Liderança de Equipes, Estratégia e Transformação Digital Um ponto importante é que essas trilhas não funcionam como caminhos isolados. Muitos profissionais começam em Redes de Computadores e, posteriormente, migram para Computação em Nuvem ou Segurança da Informação. Outros ingressam em áreas técnicas e, com o tempo, assumem posições ligadas à Governança de TI e liderança. A escolha inicial ajuda a construir direcionamento, mas não determina toda a trajetória profissional. Para quem está realizando uma transição de carreira para TI, compreender essas conexões ajuda a tomar decisões mais conscientes e identificar em que áreas suas habilidades podem gerar mais valor.  Quero conhecer as formações da ESR O primeiro passo importa mais do que a escolha perfeita Uma das armadilhas mais comuns de quem está planejando uma transição de carreira para TI é acreditar que existe uma escolha perfeita esperando para ser encontrada. Na prática, o mercado de tecnologia funciona de maneira diferente. Boa parte dos profissionais que hoje ocupam posições estratégicas não iniciou a carreira exatamente onde está atualmente. Muitos começaram em suporte técnico, migraram para Redes de Computadores e depois seguiram para Computação em Nuvem ou Segurança da Informação. Outros construíram uma trajetória técnica antes de assumir funções ligadas à Gestão de TI. Há ainda quem tenha vindo de áreas completamente diferentes e encontrado espaço na tecnologia justamente por conseguir combinar conhecimentos prévios com novas competências. Por isso, a escolha da primeira trilha deve ser vista menos como uma decisão definitiva e mais como a construção de uma base de desenvolvimento profissional. Os conhecimentos adquiridos em Redes de Computadores ajudam a compreender os ambientes de Computação em Nuvem. Conceitos de infraestrutura, identidade digital e proteção de acessos aparecem constantemente em carreiras em Cibersegurança. Experiências em liderança, planejamento e processos podem acelerar o desenvolvimento de uma gestão de TI carreira. As fronteiras entre essas especialidades existem, mas elas são muito mais conectadas do que parecem para quem está chegando agora ao setor. O que realmente costuma dificultar a entrada na área não é a escolha da trilha inicial. O desafio geralmente surge quando o profissional tenta aprender tudo ao mesmo tempo, sem critérios claros para priorizar conhecimentos e desenvolver competências. Nesse cenário, é comum acumular cursos, acompanhar conteúdos de diferentes áreas simultaneamente e consumir uma grande quantidade de informações desconectadas. O resultado costuma ser o oposto do esperado: mais dúvidas e menos direção. Por outro lado, quem investe em uma formação em tecnologia estruturada consegue construir conhecimento de forma progressiva, compreender as relações entre as diferentes especialidades e desenvolver competências que permanecem relevantes mesmo quando ferramentas e tecnologias evoluem. 💡Você também pode gostar – Tecnologias emergentes para TI: arquitetura de malha de segurança cibernética Como começar sua transição de carreira para TI com mais segurança? Independentemente da trilha escolhida, existe um fator comum entre os profissionais que conseguem se posicionar melhor no mercado – eles constroem conhecimento de forma estruturada. Essa característica se tornou ainda mais importante em um setor que evolui rapidamente e oferece uma quantidade quase infinita de cursos, conteúdos, especializações e certificações de TI. Ter acesso a uma formação organizada ajuda não apenas a aprender os conceitos técnicos necessários para cada área, mas também a compreender quais competências realmente são valorizadas pelas organizações e como elas se conectam ao longo da carreira. Isso faz diferença especialmente para quem está tentando ingressar no mercado de TI pela primeira vez e ainda busca entender quais conhecimentos geram maior impacto na empregabilidade. Antes de montar sozinho um plano de estudos baseado em conteúdos dispersos pela internet, vale considerar trilhas de aprendizagem que ofereçam progressão técnica, direcionamento e alinhamento às necessidades reais das empresas. Afinal, construir uma carreira em tecnologia envolve muito mais do que acompanhar tendências. Envolve desenvolver fundamentos sólidos capazes de sustentar o crescimento profissional ao longo dos anos. Conheça as Trilhas de Formação da ESR As Trilhas de Formação da ESR foram desenvolvidas para apoiar profissionais em diferentes momentos da carreira, desde quem está iniciando sua jornada até quem deseja aprofundar conhecimentos em especialidades específicas. Com programas estruturados em Redes de Computadores, Computação em Nuvem, Segurança da Informação e Gestão de TI, a ESR oferece percursos de aprendizagem alinhados às demandas atuais do mercado e às competências mais valorizadas pelas organizações. Cada trilha foi construída para proporcionar uma evolução progressiva do conhecimento, permitindo que profissionais desenvolvam fundamentos sólidos antes de avançar para temas mais especializados. Para quem busca uma transição de carreira para TI, esse modelo ajuda a reduzir a sensação de dispersão causada pelo excesso de informações disponíveis e oferece um caminho mais claro para o desenvolvimento profissional. Conheça as Trilhas de Formação da ESR e descubra qual delas faz mais sentido para os seus objetivos profissionais. FAQ – Perguntas frequentes sobre transição de carreira para TI 1. Qual a melhor área de TI para começar em 2026? Não existe uma resposta única. A melhor escolha depende dos interesses, das experiências anteriores e dos objetivos profissionais de cada pessoa. Redes de Computadores, Computação em Nuvem, Cibersegurança e Gestão de TI continuam oferecendo oportunidades relevantes para quem deseja iniciar uma carreira em tecnologia. 2. Preciso saber programar para trabalhar com TI? Não necessariamente. Diversas áreas da tecnologia, como Redes de Computadores, infraestrutura, governança, gestão de serviços e parte das funções relacionadas com a Segurança da Informação, não exigem conhecimentos avançados de programação como requisito inicial. 3. Vale a pena fazer uma transição de carreira para TI após os 30 anos? Sim. O setor recebe profissionais de diferentes idades e formações. Experiências anteriores em gestão, processos, atendimento, engenharia ou negócios podem inclusive representar diferenciais competitivos em determinadas funções. 4. Redes ou Computação em Nuvem: qual é melhor para iniciantes? As duas opções podem ser interessantes. Redes de Computadores costuma oferecer uma compreensão ampla da infraestrutura tecnológica, enquanto Computação em Nuvem apresenta forte demanda por profissionais qualificados e um ecossistema consolidado de certificações de TI. 5. Cibersegurança é uma boa área para quem está começando? Sim, especialmente para profissionais com perfil analítico, interesse por investigação, gestão de riscos e proteção de ambientes digitais. Entretanto, muitas funções dentro das carreiras em cibersegurança exigem conhecimentos de infraestrutura, sistemas e redes, o que torna uma formação estruturada ainda mais importante para quem está iniciando. 6. Qual certificação pode ajudar nos primeiros passos da carreira? A certificação ideal depende da trilha escolhida. Para quem pesquisa sobre nuvem AWS iniciante, certificações como AWS Cloud Practitioner costumam ser uma das portas de entrada mais conhecidas. Já em outras áreas, cursos de fundamentos podem representar um ponto de partida mais adequado do que certificações avançadas. O mais importante é compreender que as certificações fazem mais sentido quando estão inseridas em um processo consistente de formação em tecnologia, alinhado aos objetivos profissionais de longo prazo.  Quero conhecer as formações da ESR

É comum que a gestão de contratos de TI ganhe atenção quando o orçamento começa a apresentar sinais de desgaste. Na maioria dos casos, esse desgaste não decorre de falhas isoladas, mas do acúmulo de decisões contratuais pouco estruturadas ao longo do tempo. Cláusulas pouco específicas, índices de reajuste mal definidos, ausência de métricas de desempenho e contratos fragmentados criam um cenário no qual os custos aumentam sem visibilidade proporcional. Análises de mercado sobre governança de TI e procurement (aquisição) indicam que uma parcela relevante do desperdício orçamentário em tecnologia está associada à má gestão contratual, seja por ausência de monitoramento, seja por fragilidades na negociação inicial. Na prática, isso significa que o orçamento de TI não é comprometido apenas por investimentos mal planejados, mas por contratos que operam sem controle efetivo. Para gestores que precisam justificar cada investimento e profissionais que lidam diretamente com fornecedores, esse cenário cria um problema recorrente – o contrato não se apresenta como um instrumento de proteção financeira, atuando, na verdade, como fonte de risco. Ao longo deste conteúdo, vamos analisar cinco erros frequentes na gestão de contratos de TI que impactam diretamente o orçamento e aprender a corrigi-los com uma abordagem mais estratégica. Cinco erros na gestão de contratos de TI que aumentam custos e reduzem controle A gestão de contratos de TI influencia diretamente a previsibilidade financeira, a qualidade dos serviços solicitados e a capacidade de negociação com fornecedores. Quando contratos de tecnologia são estruturados sem critérios claros de desempenho, controle e revisão, passam a gerar custos recorrentes que não estão necessariamente associados à entrega de valor. Os erros a seguir aparecem com frequência em ambientes corporativos e afetam desde a execução operacional até a governança de TI e o compliance contratual. 1. SLAs sem penalidade real Acordos de nível de serviço (Service Level Agreement – SLA) são cláusulas contratuais que definem os padrões mínimos de desempenho que um fornecedor deve cumprir. Esses acordos estabelecem indicadores como disponibilidade do serviço, tempo de resposta, prazo para resolução de incidentes e parâmetros técnicos de qualidade, como latência, taxa de erro e velocidade. No contexto de serviços contínuos, como telecomunicações e infraestrutura de rede, a disponibilidade se torna um dos principais indicadores. Ela representa o percentual de tempo em que o serviço permanece operacional. A relação é direta: Disponibilidade = 1 – Indisponibilidade[1]  Um serviço com 99,9% de disponibilidade, por exemplo, pode ficar indisponível por até 8,76 horas ao longo de um ano. Quando esse serviço depende de múltiplos componentes (como acessos locais e backbone), a disponibilidade total se reduz, podendo chegar a cerca de 99,7%, o que representa mais de 26 horas de indisponibilidade anual. Esse tipo de variação raramente é considerado na negociação inicial. Até porque a disponibilidade não é o único fator relevante. Um sistema pode continuar “ativo” e ainda assim operar com degradação, velocidade reduzida, aumento de erros ou latência elevada, impactando diretamente a operação sem necessariamente ser classificado como indisponível. O risco se intensifica quando esses indicadores não estão vinculados a penalidades proporcionais ao impacto da falha. Sem consequência financeira relevante, o fornecedor não possui incentivo econômico para manter o nível de serviço acordado. Como resultado, o custo da indisponibilidade ou da degradação recai sobre a empresa contratante, fazendo com que o SLA perca sua função como instrumento de controle. Esse desequilíbrio mantém o compromisso formal, mas não protege a operação. Em uma estratégia de gestão de contratos de TI orientada à governança de TI, o SLA precisa ser estruturado como mecanismo ativo de proteção financeira e operacional. Isso envolve: ●  Métricas objetivas, auditáveis e alinhadas ao impacto no negócio; ●  Definição clara de indisponibilidade e de níveis de degradação do serviço; ●  Critérios transparentes de medição (incluindo serviços compostos por múltiplos componentes); ●  Penalidades proporcionais ao impacto financeiro e operacional; ●  Prazos definidos para resposta e resolução de incidentes; ●  Cumulação do histórico de indisponibilidade ao longo dos meses, impedindo que o saldo seja zerado mensalmente. Além da definição contratual, a gestão precisa atuar no acompanhamento contínuo desses indicadores, ou seja, monitorar o desempenho real, validar medições, registrar desvios e acionar mecanismos de compensação sempre que necessário. Sem esse acompanhamento, o SLA permanece como um número no contrato. Com gestão ativa, ele opera como instrumento de controle, negociação e proteção do orçamento. 2. Ausência de cláusulas de saída e o risco de vendor lock-in A entrada em contratos de tecnologia costuma receber mais atenção do que a saída. Esse desequilíbrio é um dos motivadores de um dos riscos mais relevantes na gestão de contratos de TI: o vendor lock-in. Vendor lock-in ocorre quando a substituição de um fornecedor se torna tecnicamente complexa, financeiramente onerosa ou operacionalmente arriscada. Um cenário diretamente relacionado com a forma como o contrato foi estruturado. Cláusulas de rescisão pouco detalhadas, ausência de regras para a portabilidade de dados e falta de previsão de suporte na transição limitam a capacidade de decisão da empresa ao longo do tempo. Na prática, isso pode envolver: ●  Dificuldade de extrair dados em formatos utilizáveis; ●  Custos adicionais não previstos para migração; ●  Dependência de tecnologias proprietárias; ●  Ausência de suporte no encerramento do contrato. O impacto mais relevante, no entanto, aparece na perda do poder de negociação. Sem alternativas viáveis, a empresa tende a manter contratos mesmo diante de condições desfavoráveis. Dentro da governança de TI, a cláusula de saída precisa garantir: ●  Prazos e condições claras de rescisão; ●  Portabilidade de dados em formatos estruturados; ●  Suporte técnico durante a transição; ●  Transparência sobre custos de encerramento. A capacidade de saída preserva a flexibilidade estratégica e evita a dependência contratual. 3. Reajustes contratuais sem limite e sem previsibilidade Cláusulas de reajuste são comuns em contratos de tecnologia, mas sua estrutura impacta diretamente o controle financeiro. O uso de índices como IGP-M ou IPCA é recorrente. O problema surge quando esses reajustes não possuem limite ou critério de revisão. Em cenários de variação econômica, os valores podem crescer de forma desproporcional à entrega do serviço. Há, assim, um descolamento entre custo e valor, com reflexos diretos no aumento acumulado ao longo do tempo, dificuldade de prever custos futuros, pressão sobre o orçamento de TI e redução da capacidade de investimento. Esse efeito é ainda mais devastador em contratos de longa duração, nos quais reajustes sucessivos ampliam o impacto financeiro. Uma gestão de contratos de TI orientada à previsibilidade deve considerar: ●  Definição do teto de reajuste (price cap); ●  Escolha adequada do índice de correção; ●  Revisão periódica das condições contratuais; ●  Alinhamento entre reajuste e desempenho do serviço. 4. Uso descentralizado de tecnologia e ausência de controle contratual (shadow IT) O uso corporativo de tecnologia se expandiu para além da área de TI, permitindo que diferentes departamentos contratem ferramentas de forma independente. Esse movimento, conhecido como shadow IT, impacta diretamente a gestão de contratos de TI. Sem controle centralizado, contratos são firmados de forma isolada, sem padronização ou visibilidade consolidada. As desvantagens dessa abordagem aparecem na operação e no orçamento com contratação duplicada de soluções, pagamento por licenças não utilizadas, ausência de negociação estratégica com fornecedores e dificuldade de consolidar custos. Além disso, a falta de visibilidade compromete a aplicação de políticas de governança de TI, já que não há controle completo sobre o ambiente tecnológico. Com isso, os riscos relacionados com a segurança da informação e o compliance também aumentam exponencialmente. Para mitigar esses efeitos, é necessário: ●  Centralizar processos de contratação; ●  Manter o inventário de ativos e contratos atualizado; ●  Padronizar fornecedores e critérios de aquisição; ●  Acompanhar o uso e o custo das soluções. 5. Falta de centralização e monitoramento dos contratos Em geral, contratos de TI estão distribuídos entre diferentes áreas, sistemas e responsáveis. Essa fragmentação reduz a eficiência da gestão de contratos de TI e compromete a tomada de decisão. Sem a centralização, torna-se difícil acompanhar informações críticas como prazos, valores e níveis de serviço, bem como há: ●  Perda de prazos de renovação ou renegociação; ●  Renovações automáticas sem análise estratégica; ●  Dificuldade de avaliar o desempenho de fornecedores; ●  Ausência de indicadores consolidados de custo. Nesse contexto, os contratos continuam ativos sem revisão de sua aderência às necessidades da organização. Quando não há integração entre TI, jurídico, financeiro e procurement (aquisição), o cenário se torna um pouco mais desafiador. Por isso, uma boa e estruturada abordagem de governança de TI exige: ●  Centralização das informações contratuais; ●  Acompanhamento contínuo de prazos e condições; ●  Análise periódica de desempenho e custos; ●  Integração entre as áreas envolvidas. A visibilidade permite transformar contratos em instrumentos de gestão. Como corrigir falhas na gestão de contratos de TI com uma abordagem estratégica Os erros analisados anteriormente não ocorrem de forma isolada. Em muitos casos, eles coexistem dentro da mesma organização e se reforçam mutuamente, criando um ambiente em que custos, riscos operacionais e fragilidade contratual evoluem em paralelo. Corrigir esse cenário exige mais do que ajustes pontuais em cláusulas específicas. A gestão de contratos de TI precisa ser tratada como uma prática contínua, integrada à governança de TI, à gestão financeira e à operação. Isso implica estruturar um modelo capaz de sustentar não só uma boa negociação inicial, mas também acompanhamento, revisão e reação ao longo de todo o ciclo de vida contratual. Anteriormente, mostramos os riscos que impactam o orçamento das empresas e deles retiramos também as dicas para uma gestão de contratos de TI eficiente: Resumo dos erros e de como corrigi-los na gestão de contratos de TI Após analisar os riscos e as formas de correção, é possível consolidar os principais pontos em uma visão comparativa.  Esse tipo de estrutura facilita decisões rápidas e reforça o papel estratégico da gestão de contratos de TI dentro da governança de TI. Erro identificado Impacto no orçamento Como corrigir SLAs sem penalidade real Alto Vincular métricas a penalidades financeiras proporcionais Ausência de cláusula de saída (vendor lock-in) Alto Definir condições de transição, portabilidade e encerramento Reajustes sem controle (sem price cap) Médio/Alto Estabelecer limites e critérios claros de reajusteIncluir a gestão de ativos e shadow IT Falta de gestão de ativo Médio/Alto Integrar contratos ao inventário e ao uso real de recursos Fragmentação e falta de centralização Médio Criar repositório único e automatizar alertas contratuais Gestão de contratos de TI como instrumento de controle financeiro Ao longo do texto, vimos que os erros apresentados têm um ponto em comum – eles não surgem por desconhecimento absoluto, mas por lacunas na forma como os contratos são interpretados, acompanhados e utilizados no dia a dia. A maioria das organizações, embora possuam contratos formalmente estruturados, lida com a ausência de capacidade para extrair deles inteligência operacional. É essa lacuna que explica por que as cláusulas existem, mas não protegem. Por isso, a gestão de contratos de TI, nesse nível, não pode ser tratada como uma atividade documental. Deve ser encarada por gestores e profissionais de TI como uma competência técnica, que exige a leitura crítica de cláusulas, o entendimento de métricas de desempenho, a capacidade de relacionar contratos com arquitetura tecnológica e o domínio sobre como essas variáveis impactam o orçamento ao longo do tempo. Sem esse repertório, a empresa pode conseguir negociar, mas não vai sustentar a negociação. Em outras palavras, a gestão contratual não é só um processo operacional, ela demanda uma formação especializada. Se sua empresa já enfrenta pressão sobre orçamento, dificuldade em renegociar contratos ou baixa previsibilidade de custos, o desafio está nos contratos existentes e na capacidade de operá-los com precisão técnica. A Escola Superior de Redes estruturou a formação em Gestão de Contratos de TI para desenvolver exatamente essa competência: conectar cláusulas, desempenho e impacto financeiro dentro de um modelo aplicável à realidade das organizações.  Conheça a formação e prepare sua equipe para atuar com mais controle, previsibilidade e poder de negociação FAQ – Perguntas frequentes sobre Gestão de contratos de TI 1 – O que é gestão de contratos de TI? É o conjunto de práticas utilizadas para planejar, negociar, acompanhar e revisar contratos relacionados com serviços e soluções de tecnologia, garantindo controle financeiro, conformidade e desempenho. 2 – Como a gestão de contratos de TI ajuda a reduzir custos? Ao permitir visibilidade das cláusulas, uso real de serviços, reajustes e desempenho de fornecedores, a gestão contratual evita desperdícios, renovações indevidas e pagamentos por serviços não entregues conforme o contratado. 3 – O que é SLA em contratos de TI? Service Level Agreement (SLA) é um acordo que define os níveis mínimos de serviço, como disponibilidade e tempo de resposta, além de critérios de medição e, quando bem estruturado, penalidades por descumprimento. 4 – O que é vendor lock-in em contratos de tecnologia? É a situação em que a empresa se torna dependente de um fornecedor, enfrentando dificuldades técnicas ou financeiras para migrar serviços ou encerrar o contrato. 5 – Quais são os principais erros em contratos de TI? Entre os mais comuns estão: SLAs sem penalidade, ausência de cláusula de saída, reajustes sem controle, falta de gestão de ativos e contratos descentralizados. 6 – Quem deve ser responsável pela gestão de contratos de TI? A responsabilidade deve ser compartilhada entre áreas de TI, jurídico, financeiro e procurement, com definição clara de papéis dentro da governança de TI. Quero conhecer melhor a formação de Gestão de Contratos de TI da ESR