While it's already been said, I'm going to stick this here so it's not hiding in comments. Mainly because, from what you've said, you've just gone ahead and applied your new policy at the domain root without even testing it on a sub-OU first?
That is an incredibly risky idea and you're lucky you haven't locked out your DCs or something.
Number one - get rid of your bitlocker policy at the domain root. Pretty much the only policies you should have there are your baseline security policies, such as password length, account lockout, all that fundamental stuff.
Secondly, start thinking about how your policies are going to be scoped. Should they really apply to every single object in the domain, or should they be applied just to computers or users? Or selected users or computers? This informs how you're going to link your policies.
Put all your computer objects into one OU (or a top-level OU and then sub-OUs as needed). I highly recommend you have separate top-level OUs for member servers and member workstations. Apply your bitlocker policy at the top-level workstations OU and/or the servers OU as required.
If you want to exclude the policy from your "security" computers (such irony), then create another top-level OU for those.
For general management, don't mix user objects and computer objects in the same top-level OUs. It's a pain to manage and makes LDAP queries very inefficient once the domain gets bigger. Put the same object classes (e.g. Users, Computers) into individual OUs, then create sub-OUs for those objects if required.
Don't fall into the legacy trap of creating sub-OUs for every department unless you literally have separate IT management teams for each one - you only need new sub-OUs if you need to customise OU permissions or policies. For policies, these days I'd generally recommend using AD groups for user/computer objects you want to target or computer WMI queries to limit the scope for granular policies).
Oh, and make sure you're not leaving user or computer accounts in the default Users or Computers containers. The only thing that should be in Users are the default accounts and groups that get created in the domain (and some of these should be moved for security purposes in due course - any account created subsequently should go into an appropriate OU.
And do some training on group policy management.