TL;DR Design documentation is important for more reasons that just satisfying an audit. You can't hide behind Agile as an excuse for not maintaining good design documentation. Find a way to automate the maintenance of your docs and enjoy the benefits, including complying with company policies.
Is it unethical to produce a document solely to pass an audit? Probably. But you're missing the point of design documentation. It is important enough to your company that they have made the design artifacts a part of the quality/process audit that they perform.
You have not tagged your post with the industry you work in, but if you work in a safety critical (eg, automotive, industrial, aerospace), or a highly regulated (eg, financial, medical) industry, there may be regulatory requirements for design documentation.
Even if it's not required by a regulatory body, maintaining design documentation is good for bringing on new team members and helping them ramp up and become familiar with the structure of the project.
Working in an agile methodology does not excuse you from good software development practices. Somebody needs to be thinking about how each new story fits into the whole. You don't want to build a frankenstein product.
The trick is to find a way to automate the maintenance of your documentation so it can follow along with the development, and someone can easily review it and add technical debt cleanup tasks to your board as needed.
Javadoc, XmlDoc (.NET), and Doxygen (multi-language support) are all good tools for maintaining the "Design" of your system, and keeping it up to date. You can add a step to you continuous integration pipeline to create the docs every time a build is done. As with anything, though, thoughtless input = meaningless output, so make sure you're actually documenting things. Doxygen is a strong tool for this since it also makes it easy to create UML diagrams and call graphs embedded into your documentation. (I am in no way affiliated with Doxygen, other than being a happy user of it.)
By automating the maintenance of your design documentation, you will always have it handy for the audits, and it will always be current for your team's use.
It sounds as though your company lives in a waterfall world. If your team has decided to go agile, it is your team's responsibility to maintain documentation to meet your company's needs. Going agile does not excuse you from this.
If your company has gone agile, then the audits will eventually reflect this. But it may take a while. Either way, your team needs to comply with the audits, so make it as easy as possible for everyone.
It is unlikely this documentation will be a one-time thing. Do what you can to make sure it stays useful once it is created.