CompTIA SecAI+ — Questões de prática e simulado

Separe os requisitos e veja qual tecnologia atende a cada um. Criar um ticket, reunir os logs relevantes e sugerir um playbook são três ações em três sistemas diferentes, ou seja, orquestração. Executá-las automaticamente quando um alerta de severidade alta dispara é automação orientada por IA. Deixar a decisão final com um analista é validação human-in-the-loop. Uma plataforma SOAR — security orchestration, automation and response — é a categoria feita exatamente para essa combinação: conjuntos pré-configurados de ações de remediação que rodam automaticamente quando um alerta ou incidente corresponde a uma regra, ou que um analista dispara manualmente durante uma investigação.

Cada alternativa descarta um dos requisitos. Regras de correlação estáticas detectam e alertam, mas não agem, então nenhum ticket é aberto e nenhum log é coletado. Um chatbot sem integrações consegue conversar sobre um incidente, mas não alcança o sistema de tickets nem o repositório de logs, então nada do que ele sugere pode ser executado. Um runbook manual movido por jobs agendados não é orientado a eventos nem adaptativo, já que roda por temporizador independentemente do que aconteceu e uma pessoa ainda executa cada passo.

Dica de prova: leia os verbos do enunciado. Detectar aponta para monitoramento, orquestrar e remediar apontam para ferramentas de resposta, e um ponto de decisão humano explícito te diz que a resposta pretendida mantém o analista no circuito em vez de removê-lo.

O EU AI Act é uma legislação histórica que estabelece um framework regulatório baseado em risco para inteligência artificial. Ele categoriza sistemas de AI em quatro níveis de risco: risco inaceitável (proibido totalmente, como sistemas de social scoring), alto risco (sujeito a requisitos rigorosos, incluindo avaliações de conformidade, como AI em contratação ou aplicação da lei), risco limitado (obrigações de transparência, como chatbots que devem revelar que são AI) e risco mínimo (sem requisitos específicos, como filtros de spam). Organizações que implantam AI na EU ou processam dados de cidadãos da EU devem cumprir os requisitos do nível relevante. O Act também inclui disposições para modelos de AI de propósito geral, como large language models. Entender a classificação de risco do EU AI Act é essencial para o exame SecAI+ porque ela representa a abordagem regulatória mais abrangente para governança de AI globalmente. Dica de exame: o EU AI Act tem quatro níveis de risco — lembre-se da hierarquia de inaceitável até mínimo.

O objetivo 1.2 lista os conceitos de processamento de dados essenciais para a segurança de dados em IA: limpeza de dados, verificação, lineage, integridade, provenance, augmentation e balancing. Data provenance registra a origem e a propriedade dos dados, enquanto data lineage acompanha sua movimentação e suas transformações ao longo do pipeline; juntos, eles estabelecem a confiabilidade e apoiam auditorias e a investigação de incidentes. Isso importa para a segurança porque dados envenenados ou adulterados são muito mais fáceis de detectar quando a origem e o histórico estão documentados e são verificáveis. Não confunda provenance/lineage com augmentation (criar dados sintéticos), balancing (corrigir o desequilíbrio entre classes) ou watermarking (embutir marcas de propriedade ou detectar conteúdo gerado por IA). Dica de prova: 'de onde vieram os dados e como eles foram transformados' equivale a provenance e lineage.

Dois requisitos precisam ser atendidos por um único controle, e isso estreita o campo rapidamente. Atribuição de custo exige contabilização por consumidor; isolamento com divisão justa exige um teto por consumidor. Uma política de limite de tokens no gateway entrega as duas coisas, porque aplica limites por consumidor da API com base no consumo de tokens e te deixa definir uma taxa de tokens por minuto ao lado de uma cota em um período mais longo, atrelada a algo que identifique quem chama, como uma chave de assinatura.

Tokens são a unidade certa. Tanto o custo quanto a capacidade do backend em um modelo de linguagem escalam com tokens, e não com a quantidade de requisições, então um simples limite de requisições por minuto é uma aproximação ruim: um único prompt muito longo pode consumir mais capacidade do que mil curtos e ainda assim passar por uma verificação de taxa de requisições. Contar por consumidor é o que transforma uma válvula de segurança global em isolamento, porque um time que bate no seu teto é limitado sem encostar na folga de ninguém.

Os distratores resolvem outros problemas. Um filtro de tópicos bloqueados é um controle de segurança de conteúdo e não mede nada. O cache semântico reduz chamadas ao backend para prompts repetidos, o que ajuda no custo médio, mas não garante nada sobre justiça ou atribuição. Uma janela de contexto maior aumenta o quanto uma única requisição pode consumir, o que piora o risco de inanição em vez de melhorá-lo.

Dica de prova: quando uma questão sobre gateway junta custo com capacidade, procure o controle cuja unidade são os tokens e cujo escopo é a chave de consumidor.