In terms of OO either's valid, along with a bunch of other options too.

Encapsulation doesn't say that a class needs to hold all the implementation that's relevant to that class - it says that a class should not expose implementation to it's consumer.

In other words the thing that consumes a Policy should just know it has to call Save. It shouldn't know whether the Policy class actually implements the save or delegates it.

In a reasonably small system it might be a good design decision to have your domain classes implement their own DB code, to keep things simple. The downside would come when you wanted to change the underlying DB to, for example xml files. At that point you'd need to crack open every one of your domain classes which would be lots of work and high risk. If you'd implemented a separate data access layer (or DAL) you could simply implement a new, xml based DAL and drop it in in place of the old DB one. So the DAL adds complexity in the short term but aids flexibility in the long term.

Personally I'll always implement a separate DAL as I feel the flexibility more then pays for the extra complexity but it's not an encapsulation/OO issue.