1. Desenhar a matriz de cobertura
Numa equipa fictícia de operações de fundos, pretende-se usar um assistente para preparar resumos técnicos sem enviar dados de clientes. Começa por identidade, aplicação de destino, sentido do tráfego, tipo de ficheiro e classificação. Para AI guardrails em Secure Access, verifica inspeção HTTPS aplicável à mesma identidade e os workflows suportados. A inspeção configurada para outra equipa não demonstra cobertura desta. Usa apenas dados sintéticos nos ensaios: um número com formato reconhecível pode ser suficiente, sem copiar registos de produção. A ficha anexa é um plano por executar num tenant autorizado; não apresenta resultados reais de uma plataforma Cisco nem procedimentos internos de qualquer banco.
2. Separar correspondência, ação e resultado
Um evento de classificação diz que houve uma correspondência observada. Para concluir prevenção, confirma a ação Block aplicável e o resultado do envio no fluxo suportado. Monitor permite observar sem oferecer a mesma conclusão de bloqueio. A severidade atribuída ajuda na priorização, mas não substitui a ação. Uma notificação também não prova que o destino deixou de receber os dados. Na revisão de política, inspeciona inclusões e exclusões da regra; uma identidade excluída não deve ser contada como protegida por essa mesma regra. Isto não permite concluir que todas as outras políticas a deixam passar. Regista cada camada e evita extrapolar uma decisão local para o serviço inteiro.
3. Exercitar fronteiras e exceções
Planeia pares de ensaios: prompt sensível e prompt benigno, identidade incluída e excluída, interface web e outra integração utilizada pelo negócio. Confirma suporte antes de atribuir a mesma proteção à API de uma aplicação. Se a regra se destina apenas a respostas, não a contes como proteção dos prompts. Na classificação de ficheiros, distingue nomes técnicos de labels de texto de apresentação e inclui documentos sem label; ausência de label não significa informação pública. O limite documentado de inspeção de conteúdo deixa de fora texto além dos primeiros 50 MB. Um filtro de tamanho mais amplo não demonstra inspeção integral. Mantém esses casos na matriz e define tratamento alternativo para o risco residual.
4. Interpretar qualidade sem esconder falhas
A ficha inventa cem casos classificados manualmente: vinte sensíveis e oitenta benignos. O mecanismo hipotético deteta dezoito sensíveis, falha dois e assinala quatro benignos. Recall é 18/20, ou 90%; precision é 18/22, cerca de 81,8%; falsos positivos são 4/80, ou 5% dos benignos. Accuracy é 94/100, mas esse número oculta duas perdas de dados possíveis. Não são resultados medidos da Cisco. Investiga o tipo e gravidade dos casos falhados antes de aceitar a mudança. Repete positivos e negativos após afinar identificadores ou limiares. Uma exceção precisa de motivo, âmbito, responsável, prazo e controlo compensatório, com revisão posterior em vez de exclusão indefinida.
5. Entregar operação e limites de proteção
Distingue proteção em linha de análise de ficheiros armazenados por API SaaS. Iniciar um discovery scan não significa que todos os ficheiros ficaram inspecionados; permissões, âmbito, filas, formatos e limites do serviço influenciam o resultado. No handover, entrega o inventário de destinos suportados, matriz de ensaios executados, métricas por classe, exceções e responsável por triagem. Um classificador de conteúdo sensível não garante que a resposta de um LLM é verdadeira nem resolve todas as formas de prompt injection. Para o resumo técnico, conserva revisão humana e restringe ferramentas e dados segundo o caso de uso. Resumo: a aceitação exige cobertura demonstrada, efeito observado e risco residual assumido pelo responsável adequado.
18 deteções corretas, 2 falhas e 4 falsos alertas: recall 90%, precision 81,8%. São valores fictícios para interpretar, não um benchmark.
Armadilhas comuns
Monitor como bloqueio; evento como prevenção; ausência de label como público; accuracy isolada; descoberta iniciada como cobertura completa.
Tópicos relacionados: SSE e inspeção HTTPS · Classificação de dados · Risco de IA
DLP deve ser aceite pelo fluxo e resultado demonstrados, com limitações e exceções explícitas.
Referência: Add an AI Guardrails Rule to the Data Loss Prevention Policy · 350-701 SCOR v2.0, effective 2026-08-27; core component of CCNP Security