Decide whether the person may continue
A team may want to see how often a new project name appears in supported AI activity before introducing a restriction. Log can help with that observation, but it does not prevent submission. If the project material must not leave through a supported route, observation alone will not meet that requirement.
Warn is suitable only when continuing is an acceptable option under your process. A person can acknowledge a warning and carry on. Use Block for a configured match that must stop the supported submission, then test that outcome. Do not describe a warning policy as prevention in a deployment report.
For redaction, test what remains
Suppose a reply-drafting task needs the customer's question but not their email address. Redact may be useful if the supported workflow can replace the matched address and send the remaining text correctly. Verify the outgoing result and whether it still makes sense for the task.
Decide what should happen when the content cannot be safely redacted. A file may be encrypted, an image may contain text the scanner cannot read, or an encoded match may lack a reliable replacement location. Where prevention is required, configure the applicable fallback to Block and test that case too. Do not assume every file can be rewritten.
Start narrowly enough to understand the result
A broad word such as 'client' can match ordinary work all day. A specific internal project phrase is easier to test and explain. Start with the tools, people and data involved in the actual task, then check examples that should match and examples that should pass.
Have an administrator review unexpected matches with the team. Adjust the rule when the evidence supports it, keep the intended action clear, and repeat the affected tests. This is slower than switching on every rule at once, but it gives people a policy they can understand and administrators a result they can investigate.