Securing Data via secret key that must be revealed later
If I understand you correctly,
you want to set up a system such that


Alice stores encrypted data on Ted's servers
Some event occurs that tells Ted to do something.
Sometime before that event, Alice has disappeared and becomes unable to perform any other steps in the protocol.
Everyone wants Bob to recover the plaintext of Alice's data after the event.
Ted is never able to recover the original plaintext. (In other words, this is a "host-proof" protocol. See host-proof for many related questions and answers).
Bob is not able to recover the original plaintext before the event, only after Ted cooperates by doing ... something.
Bob doesn't need to actively communicate with Bob or Ted or even know Alice exists before the event.


It seems clear to me that Bob needs to know (or be able to find out) something that Ted doesn't know. If Ted hypothetically knows everything that Bob knows, then by the time Bob receives a message from Ted and has all the information needed to decrypt the data, Ted has long before that time already has all the information needed to decrypt the data, which means that hypothetical protocol fails to be host-proof.

It also seems clear that we must trust Ted to actually send something to Bob after the event.
If hypothetically both Alice and Ted refuse to communicate after the event, then Bob won't learn anything that he doesn't already know, and therefore either Bob has long before the event already had all the information he needs to recover the plaintext, or else he never is able to recover the plaintext -- both undesired.

Off the top of my head, one possible approach could be:

Ted and Trent: two trusted hosts


For each document, Alice generates a random symmetric key, encrypts the document with that symmetric key, and stores the resulting encrypted document on Ted's server or Trent's server or both.
For each encrypted document, Alice encrypts the (symmetric) key used to encrypt that document using a one-time pad. This splits the key into 2 pieces -- an encrypted symmetric key, and a piece of one-time pad that can later be used to decrypt it. (This is "trivial secret sharing". Any other secure form of secret splitting would also work. Other forms of secret splitting might work even better).
For each encrypted document, Alice stores one piece of the split key on Ted's servers and the other piece on Trent's servers, but never sends all the pieces of the split key to any one person.
After the event, both Ted and Trent send all data they got from Alice to Bob. (In principle, Ted and Trent could send all the encrypted documents to Bob ahead of time, and send either one part of the split key or the other -- but not both -- to Bob ahead of time).
Once Bob receives the encrypted version of a document and all the pieces of a split key for that document, Bob combines the split key to recover the original symmetric key, then uses that symmetric key to recover Alice's plaintext document.


Given the initial constraints, I don't see any way around trusting Ted not to reveal some information to Bob prematurely.
This protocol has the additional weakness of trusting Ted not to (ever) reveal information to Trent, and also vice-versa.