The typical use of AR violates these principles. Many developers dump every possible piece of functionality into their models making them fat and cumbersome. The fact that AR makes database interactions an afterthought aids in the misuse.
What you could do is make use of the repository pattern.
Use it to separate your data persistence code from the business logic thus hiding away the details of AR. Then separate your use cases into single responsibility classes. Recently this has been dubbed DCI and it's starting to gain some traction. This will keep your models uber-light and use cases will become more clearly articulated in real classes. Learning to make use of DCI takes some practice but there are a growing number of resources out there and really, once you grok the concept, you shouldn't have much trouble using it. (Don't worry if you make some initial mistakes.)
By taking this tack you wouldn't be tightly bound to AR. You could very easily create interfaces that use the filesystem or any sort of persistence. By making your persistence layer more of an afterthought, you'll have improved your architecture dramatically.