Durante muito tempo, a arquitetura de um programa de conscientização em segurança foi relativamente simples. A organização disponibilizava um treinamento anual, realizava algumas campanhas de phishing ao longo do ano, enviava comunicações periódicas e acompanhava indicadores como conclusão, notas das avaliações e taxa de clique.
Esse modelo ainda possui valor. O treinamento anual cria uma base comum de conhecimento e, em muitas organizações, também atende requisitos regulatórios, contratuais ou de compliance. Simulações de phishing continuam sendo uma excelente fonte de informação sobre comportamento. Campanhas de comunicação ajudam a manter segurança presente na rotina.
O problema aparece quando tentamos tornar o programa “contínuo” simplesmente aumentando a frequência dessas atividades.
Mais treinamentos, mais e-mails, mais campanhas e mais simulações não produzem necessariamente mais segurança. Dependendo da frequência e da relevância, podem produzir exatamente o contrário: fadiga, redução de atenção e a percepção de que conscientização é apenas mais uma sequência de tarefas corporativas que precisa ser concluída.
Continuous Awareness precisa significar algo diferente.
Do ponto de vista técnico, um programa contínuo deveria funcionar como um sistema capaz de combinar um baseline comum com intervenções menores e mais contextuais ao longo do tempo. Em vez de perguntar apenas qual treinamento será enviado no próximo mês, começamos a perguntar quais sinais justificam uma intervenção, qual população realmente precisa dela, qual formato é mais adequado e como saberemos posteriormente se aquela ação funcionou.
A primeira camada continua sendo relativamente tradicional. Existem conhecimentos que toda a população precisa possuir independentemente de função, área ou nível de risco. Engenharia social, proteção de credenciais, uso adequado das informações, mecanismos de reporte, responsabilidades relacionadas às políticas corporativas e outros fundamentos podem compor esse baseline.
Em setores regulados, essa camada também pode estar associada a obrigações de capacitação periódica e às evidências necessárias para demonstrar que a organização dissemina adequadamente suas políticas e práticas de segurança.
Do ponto de vista de arquitetura, o baseline possui uma característica importante: sua população é ampla e previsível. Conseguimos definir conteúdo, periodicidade, público, critérios de conclusão e evidências necessárias.
Mas essa camada responde principalmente à pergunta: **o que todos precisam saber?** Continuous Awareness começa quando adicionamos uma segunda pergunta: **o que determinada pessoa ou grupo precisa saber agora?**
São problemas diferentes e, portanto, deveriam ser tratados por mecanismos diferentes.
Imagine que uma organização identifique crescimento de ataques utilizando QR Codes. Não existe razão para esperar pelo próximo ciclo anual para abordar quishing. Uma comunicação curta, um microlearning ou uma simulação específica podem ser utilizados imediatamente.
Agora imagine outra situação. Um grupo de colaboradores começa a utilizar uma nova aplicação de inteligência artificial generativa. Nesse caso, uma intervenção sobre proteção de informações e uso seguro de IA pode fazer sentido especificamente para aquela população.
Em outro cenário, uma pessoa recebe privilégios administrativos. A mudança de função ou de acesso pode justificar uma orientação sobre proteção de identidade, autenticação e ataques direcionados.
Esses exemplos possuem algo em comum: a intervenção nasce de um contexto.
É justamente isso que diferencia um calendário contínuo de uma arquitetura contínua. Um calendário diz que em março falaremos de phishing, em abril de senhas e em maio de proteção de dados. Uma arquitetura orientada a contexto continua podendo utilizar esse calendário, mas também consegue reagir a eventos que acontecem entre essas datas.
Isso significa que o programa passa a possuir duas camadas funcionando simultaneamente: uma camada planejada e uma camada adaptativa.
Para que a camada adaptativa funcione, precisamos definir quais eventos podem influenciar uma intervenção.
Alguns desses sinais já existem dentro das próprias plataformas de conscientização. Uma pessoa pode ter interagido com determinada simulação de phishing, fornecido informações em um cenário, deixado de reportar uma mensagem ou apresentado reincidência em determinado comportamento.
Outros sinais podem vir de fora do ambiente tradicional de awareness.
IAM e IGA podem indicar mudança de função, novos privilégios ou acesso a recursos críticos. DLP pode fornecer sinais relacionados ao tratamento inadequado de informações. CASB ou SSE podem indicar utilização de aplicações não autorizadas ou determinados padrões relacionados a Shadow AI. EDR e XDR podem contribuir com eventos de segurança associados a endpoints. Informações externas podem mostrar que determinadas identidades estão mais expostas a ataques ou possuem credenciais presentes em vazamentos conhecidos.
Isso não significa que cada alerta dessas ferramentas deva gerar automaticamente um treinamento.
Esse seria um dos piores desenhos possíveis. O objetivo é transformar esses eventos em contexto suficiente para decidir se uma intervenção educacional faz sentido.
[](#fale-com-especialista)
Essa distinção é fundamental. Imagine que uma ferramenta de segurança identifique uma credencial corporativa exposta em um vazamento. A resposta principal provavelmente envolve identidade: redefinição de credenciais, invalidação de sessões, investigação, autenticação e outros controles técnicos.
Enviar um treinamento pode fazer parte da resposta, mas não deveria substituir o tratamento do risco.
Da mesma forma, se uma pessoa possui privilégios excessivos, a ação adequada pode ser uma revisão de acesso. Se existe movimentação incomum de informações, talvez seja necessário investigar o evento ou ajustar controles de DLP. Se alguém apresenta dificuldade recorrente em reconhecer determinados tipos de phishing, uma intervenção educacional passa a fazer muito mais sentido.
Essa separação é importante porque Continuous Awareness não deveria transformar qualquer sinal de risco em mais conteúdo.
A arquitetura precisa conseguir distinguir situações em que educação é o tratamento principal, situações em que funciona como complemento e situações em que simplesmente não é a resposta adequada. É exatamente nesse ponto que awareness começa a se conectar com Human Risk Management.
Suponha que duas pessoas apresentem Human Risk Score elevado. Se utilizarmos apenas o valor final do score, poderíamos colocar ambas no mesmo grupo e enviar exatamente o mesmo treinamento. Tecnicamente, isso é fácil de implementar, mas perde grande parte do valor de uma abordagem baseada em risco.
Uma das pessoas pode estar com risco elevado porque apresentou reincidência em simulações de engenharia social. Nesse caso, uma intervenção relacionada à identificação de ataques pode fazer sentido.
A outra pode possuir comportamento excelente nas campanhas, mas apresentar risco elevado porque ocupa uma função altamente exposta, possui privilégios relevantes e está sendo alvo de ataques direcionados. Essa pessoa talvez precise de uma preparação diferente, focada em spear phishing, impersonation, proteção de identidade ou procedimentos específicos de verificação.
O score pode ajudar a priorizar. A causa precisa ajudar a escolher a intervenção. Por isso, uma plataforma que pretende utilizar risco para personalizar conscientização precisa preservar os fatores que explicam aquele risco. Um número isolado é insuficiente para decidir qual conteúdo deve ser apresentado.
Outro elemento importante de Continuous Awareness é abandonar a ideia de que qualquer necessidade educacional precisa resultar em um curso. Existem diferentes formatos para diferentes objetivos.
Um treinamento mais estruturado pode ser adequado para estabelecer fundamentos ou atender requisitos formais. Microlearning pode funcionar melhor para reforçar um conceito específico em poucos minutos. Uma comunicação pode alertar sobre uma ameaça emergente. Uma simulação pode observar como determinada população responde a um cenário. Um nudge pode lembrar uma prática no momento em que ela é relevante.
A arquitetura precisa permitir que esses formatos coexistam. Isso também ajuda a controlar fadiga. Se cada novo risco gerar um curso de vinte minutos, rapidamente o programa se tornará insustentável. Se conseguirmos selecionar intervenções proporcionais à necessidade, podemos manter segurança presente sem transformar conscientização em uma carga permanente.
A pergunta deixa de ser “qual treinamento devemos atribuir?” e passa a ser “qual é a menor intervenção capaz de produzir o efeito que precisamos?”.
Um dos riscos de qualquer sistema adaptativo é gerar intervenções demais. Imagine uma pessoa que apresenta vários sinais em um curto período. Uma arquitetura ingênua poderia atribuir um microlearning após um evento, uma simulação depois de outro, uma comunicação personalizada no dia seguinte e um treinamento adicional alguns dias depois.
Cada ação isoladamente pode fazer sentido. O conjunto pode produzir uma experiência péssima. Por isso, Continuous Awareness precisa trabalhar com estado.
A plataforma deve saber quais intervenções aquela pessoa recebeu, quando recebeu, por qual motivo e qual foi o resultado. Também deveria existir algum conceito de cooldown, impedindo que determinados tipos de ação sejam repetidos em intervalos inadequados.
Isso permite estabelecer políticas. Por exemplo, um evento pode aumentar a prioridade de determinada intervenção sem necessariamente executá-la imediatamente. Se a pessoa já recebeu conteúdo equivalente recentemente, talvez seja melhor aguardar ou escolher outro formato.
Esse histórico também evita loops. Sem controle de estado, um mesmo sinal persistente pode continuar gerando a mesma ação indefinidamente.
Automação sem memória produz ruído. Continuous Awareness precisa saber o que já fez.
Personalização não significa necessariamente criar um programa exclusivo para cada funcionário. Em organizações com milhares de pessoas, isso seria operacionalmente difícil e provavelmente desnecessário.
Uma abordagem mais eficiente é trabalhar com grupos dinâmicos formados por características de risco ou necessidade. Podemos ter, por exemplo, uma população mais exposta a BEC, outra com necessidade relacionada a IA generativa, uma população de identidades privilegiadas ou um grupo que apresentou dificuldade recorrente diante de determinado vetor de engenharia social.
As pessoas entram e saem desses grupos conforme seus sinais e contexto mudam. Isso permite personalização em escala. Em vez de manter milhares de jornadas individuais, mantemos um conjunto gerenciável de políticas e intervenções associadas a necessidades específicas.
Também facilita governança. Segurança consegue explicar por que determinada população recebeu uma intervenção e quais critérios determinam sua permanência naquele grupo.
Se utilizamos sinais negativos para adaptar o programa, precisamos fazer o mesmo com sinais positivos.
Uma pessoa que anteriormente apresentava dificuldade em determinado tipo de phishing pode começar a identificar e reportar corretamente os cenários. Alguém que recebeu uma intervenção pode demonstrar evolução consistente nas campanhas seguintes. Um grupo que apresentava determinada necessidade pode deixar de apresentar aquele padrão.
Esses comportamentos precisam alterar o estado do programa. Caso contrário, criamos um sistema em que erros são permanentes e melhorias são invisíveis. A pessoa entra em uma jornada adaptativa por causa de um comportamento passado e continua recebendo intervenções mesmo depois de demonstrar mudança.
Além de tecnicamente ruim, isso pode gerar uma percepção punitiva. Continuous Awareness precisa possuir critérios de entrada e critérios de saída. Se o risco diminuiu ou o comportamento melhorou de maneira consistente, a intensidade da intervenção também deveria diminuir.
Uma intervenção não deveria terminar quando alguém conclui um conteúdo. Se determinada pessoa recebeu um microlearning porque apresentou reincidência em um tipo de phishing, precisamos observar o que acontece nas interações seguintes. O comportamento mudou? Houve novo evento? A pessoa passou a reportar? Quanto tempo levou para isso acontecer?
Esse retorno é essencial porque permite medir efetividade. Sem ele, voltamos ao modelo tradicional em que sabemos que um conteúdo foi atribuído e concluído, mas não sabemos se produziu qualquer alteração.
Do ponto de vista técnico, isso cria um ciclo relativamente claro. Sinais são coletados, normalizados e associados à identidade. O contexto ajuda a determinar uma necessidade. Uma política seleciona a intervenção adequada. A intervenção é executada e registrada. Novos sinais mostram posteriormente se houve mudança.
O resultado retorna para o modelo. É esse feedback que transforma um calendário de treinamento em um sistema adaptativo.
Quanto mais contexto utilizamos para personalizar intervenções, mais importante se torna estabelecer limites claros sobre os dados utilizados. Continuous Awareness não precisa saber tudo que uma pessoa faz.
Na maioria dos casos, sinais normalizados são suficientes. Uma plataforma pode precisar saber que ocorreu determinado tipo de evento de segurança sem necessariamente armazenar todo o conteúdo associado ao evento. Pode receber uma classificação de risco proveniente de outra ferramenta sem copiar integralmente seus logs.
Princípios de minimização, finalidade, necessidade, controle de acesso e retenção precisam fazer parte da arquitetura.
Também é importante que a organização consiga explicar por que determinada intervenção aconteceu. Se alguém recebe um conteúdo específico, o sistema deveria conseguir identificar quais fatores justificaram aquela decisão.
Personalização sem explicabilidade pode rapidamente ser percebida como monitoramento. Personalização com critérios claros pode ser entendida como uma forma de oferecer orientação mais relevante.
Na prática, podemos pensar em algumas camadas. A primeira continua sendo o **baseline corporativo**, onde ficam treinamentos obrigatórios, políticas e conhecimentos comuns.
A segunda é formada pelas **fontes de sinais**, incluindo phishing simulation, LMS, mecanismos de reporte e, quando fizer sentido, integrações com IAM, IGA, DLP, CASB, SSE, EDR, XDR, SIEM e outras fontes.
Esses eventos precisam passar por uma camada de **normalização e identidade**, responsável por entender a qual pessoa ou grupo determinado sinal está associado e qual o seu significado.
Em seguida vem uma camada de **decisão**, onde políticas consideram comportamento, contexto, histórico de intervenções, temporalidade e eventualmente Human Risk Score para determinar se alguma ação é necessária.
Depois temos a camada de **intervenção**, que pode utilizar treinamento, microlearning, comunicação, simulação, nudge ou outro mecanismo.
Finalmente, precisamos de **feedback**, porque o comportamento posterior precisa retornar ao modelo para mostrar se a intervenção produziu efeito.
O fluxo deixa de ser simplesmente: Treinamento → conclusão. E passa a funcionar como: Sinal → contexto → decisão → intervenção → novo comportamento → reavaliação.
Essa diferença é pequena quando escrita em uma linha, mas representa uma mudança significativa na arquitetura do programa.
Existe uma tentação natural de medir maturidade pela quantidade de atividades realizadas. Quantos treinamentos enviamos, quantas campanhas executamos, quantas comunicações publicamos e quantas simulações fizemos durante o ano. Mas volume não é maturidade.
Um programa pode realizar dezenas de atividades e ainda assim falar com todas as pessoas da mesma maneira, independentemente de contexto, comportamento ou necessidade. Outro pode executar menos intervenções, mas utilizá-las no momento certo, para a população certa e com um objetivo claramente definido.
A segunda abordagem tende a produzir uma experiência melhor para as pessoas e informações muito mais úteis para segurança.
O treinamento anual continua tendo seu papel. Ele estabelece uma base comum e, quando necessário, atende requisitos importantes de compliance. O calendário tradicional também continua útil para organizar temas e manter uma cadência mínima.
O que muda é aquilo que construímos ao redor dessa base.
Quando conseguimos observar sinais, compreender contexto, selecionar intervenções proporcionais, controlar frequência e medir o comportamento posterior, conscientização deixa de ser uma sequência de atividades programadas e passa a funcionar como um sistema contínuo de redução de risco.
No final, Continuous Awareness não deveria significar que as pessoas estão sempre fazendo algum treinamento de segurança. Deveria significar que **a organização está sempre preparada para ensinar aquilo que importa, para quem precisa, no momento em que isso pode realmente fazer diferença**.