If you update a file, that is unlikely to be modifying the ownership. However, if you are logged in as root, you may have an issue with the idea that new files are owned by root.
One option is to chown (change ownership) of the files after they are created. This may create a "race condition" which, even if the risk is small, there is sound theory in just not creating an unlikely problem if possible.
Another option might be to upload the desired new files as an archive file as root, and then chown that file, and then extract the file as an end user.
It sounds like it may be a good idea to strongly consider just logging in as the account you want the files to be owned by. Then you have no race conditions. I realize the general desired practice of not wanting to have a service account be logged in. But what you're seeking to do is to take that general advice to an extreme level by inventing a workaround, by logging in as a different user (root) instead. And then you're coming up with some concerns about the logical impacts of the approach taken. Utilizing a not-straight-forward workaround may be more prone to causing problems, and thereby be riskier than having an account be able to log in.
As a general principle, don't take some generally-good advice to such an extreme that you inflexibly apply the suggestion in absolutely every scenario, including situations where that advice would create unnecessary significant problems.
Keep in mind that you may be able to log into this account, and then use sudo but still be restrictive. sudo can be set up to only allow specific commands (or commands that start with some specific text). I've sometimes created an account that can log in using only a specific SSH key, and which can then sudo and only run the specific command provided. Then control to run that command can be given to anyone who has that safely-guarded SSH key.
It also sounds like you might benefit from relying on "group owner" permissions (often just called "group permissions"). You may also benefit from utilizing another account, e.g. "service-account" and "account-used-for-updates" (in addition to, or instead of, using the widely known-to-be-potentially-dangerous "root" account).