You really need to do both. Here's how I would suggest doing it.
Step 1:
Get stories from management, give them to developers. They use TDD to write low-level, fast executing tests that may mock objects or use fake data to ensure things are making sense to the system they are designing within. Then they actually code the story, and do a sanity check that their expected goals match the output from their work. If not, they either change their tests, or their work, depending on the severity of the error in either the test or the code.
Step 2:
After a few dozen of these stories have been merged into a feature, they are committed to the repository and become something that users might see (in a website, or an api, etc). This is where BDD is different. Once a feature is finished you write a test that outlines the behavior of the feature as a user might describe it to someone else, and exercise the functionality not from within the system, but as much as possible, as a user would exercise your feature. That means if the feature is available over the web, use the web to get to it. If you have to enter it three forms before a new user can see a feature for the first time, fill out the three forms first. TDD will normally pretend that those three forms are already filled out for a certain test, or they may pretend to GET a resource from a server, etc (it keeps the focus of the test small, and the runtime low; two key goals of tests). BDD doesn't care if your firewall breaks a feature in production; the behavior is broken, and that's all a user cares about. So integration between many features, unexpected clashes between scenarios or unexpected outcomes from user activities are fair game for BDD. Everything is important from a high level perspective in BDD.
These tests may take several minutes to run each, and you may have hundreds of them that together take hours to run (as would be the case for smoke tests for a website). They are also written using some frameworks that abstract the plain text descriptions of the behavior that exist in the form of modules that contain code. Those methods might then generate calls to databases, servers, or local system resources to modularize "steps" that occur during these tests. The tricky part here is writing them to effectively stand apart from each other, so that they are useful on their own when used in many different tests (if you have something like logging in, writing a message to people, or some other task that is common between many different features).
