We know that you can't invert the AES encryption to determine it's key at present. So you're fine there, as long as you are able to generate all 256 bits in the uniformly distributed way. Any decent random number generator will be able to do this as long as it can be seeded correctly. If there is some mathematical relationship between the files (you derive from) and the key, you'll need to make sure that the file entropy fits into the random number generators state space. This can be a little tricky sometimes, and there are examples like the seeding mechanism of RC4 that's quite poor and can lead to /induce weak states. This then has a detrimental effect on the generator's output. Similarly, correctly seeding a large state generator like the Mersenne Twister is difficult. This is all however an implementation issue.
One security issue lies with the IV. This is stored in plain form. In order to maintain security, the IV must be generated from a cryptographically secure generator. Otherwise it might be quite simple to determine an insecure generator's state and thereby predict all IVs. Since you need a CSRNG for the IV, you might as well use the same generator for the 256 bit key. The same issue of correct seeding still remains however.
The other issue is if you transmit the same file repeatedly. The purpose of the IV is to make sure that the cipher text is unique per transmission, even if the plain text is the same. If the IV /key pair are directly (and only) related to the encrypted file contents, the cipher text will always be identical. This may not be an issue for disk storage, but can be for copying /transmission as it leaks some information.
My sense would be to have some form of salt anyway. Without it, the system feels very predictable as all the information is there in hard coded form. Something that only you know would improve the security.