Use uuid as primary and/or as surrogate key?

We are required to add UUID's to most of our objects and database tables.

Would you use the UUID as surrogate key, or rather as natural key in addition to a sequence generated surrogate key, i.e. use a private surrogate key and in addition add a column/attribute to hold the UUID?

I see that it is often used directly as surrogate / primary key. Somehow I don't like the idea.

One might view a UUID as a natural key, since it should be a unique identifier with a global meaning just like any other natural key, independent of a particular implementation of a system, i.e. if you would ever move your data to another system, the UUID must stay the same, whereas surrogate keys by definition have no real and lasting meaning.

Maybe I should have clarified more: suppose we have an Account table. Traditionally there would be some internal surrogate key and a natural key consisting of the account number (as printed on account statements etc.).

Whereas the UUID is not as "readable" as the account number, I would view a UUID more like the natural key because it could serve the same purpose as the account number: to refer to a particular account in a unique and unchanging manner. The (traditional) surrogate key never appears outside of the system, since it is completely private and could be changed at any time, no external references must ever exist to it.

In that sense a UUID is not a typical surrogate key (?).