Here's how someone can do it.

LetsEncrypt exists because identity in SSL/TLS is only about domain name ownership, which is easily checkable using automated scripts if you handwave away the question of how to securely connect to that domain without TLS - ultimately it needs DNSSEC to be theoretically sound but in practice we cross our fingers and hope for the best without it.

The standard PKI is not a monopoly, it's the opposite. It's a competitive market with several players (vs SSL certs where LE just totally dominates due to being subsidized). CAs will sell you certificates usable for PDF document signing but they have to charge money because there is no automated way to verify your legal identity, so manual labor is required and that's expensive.

Therefore, the problem of how to build a LetsEncrypt for data is the problem of how to verify identities at scale automatically. There are two possible approaches you can use here, all of which require new software or infrastructure (which is why it hasn't happened).

1. Sign documents with your domain name! There is no specific reason you can't use an SSL cert to sign a document, it's just that the certs have flags in them that say they're not meant to be used that way. But a key is a key. You can write software that will override those checks and then use the regular standards like CMS, Authenticode or PDF signatures. This could work as long as you domain name was the same as your business/project name, or otherwise unique to yourself somehow. But judges would have to accept it. In the USA it's possible because the law doesn't say much about the exact nature of digital signatures, in the EU it's probably not because the Commission has spelled out in excruciating detail exactly how the PKI and signing specs must work.

2. Verify identities using e-Passports. Every e-passport contains a signed certificate holding your personal data signed by government root authorities, including a JPEG2000 encoded image. To automatically issue a certificate against such an identity, you need:

2a. A mobile app that can dump the NFC chip contents. This is done already, you can find such apps on the Play store (dunno about iPhones though). The data in the chips are public, it's not locked down.

2b. Some way to verify that the person with the public key is the same as in the passport photo. This can be done with face recognition/matching AI.

2c. Some way to re-assure people that uploading their passport contents to a remote server isn't a dumb thing to do. This can be done by running the CA and verification logic inside an SGX enclave, with open source clients (e.g. the mobile apps) that verify the enclave's remote attestation before uploading anything. The data will be encrypted and protected from the owner of the CA hardware.

Now you can create a PKI that auto-issues certs with people's public key, legal name, country and maybe photo in them. The enclave can also issue sub-certs that reveal less information or even certs that use a keyed hash of the passport number or something to give you an anonymous yet unique credential. Of course this new PKI won't be recognized by Windows, PDF viewers, governments or anything else that consumes signatures. That's step 2.