I think that there is indeed a role for quality assurance in an agile organization, especially one that has to adhere to a quality management system such as ISO9001, ISO13485 for the medical device industry or AS9000 in the aerospace industry, for the purposes of meeting customer requirements, regulations, or corporate mandates.
There are two important things to keep in mind. First, quality assurance is not just interested in the quality of the final product, but all intermediate work products. You can view software development as a black box that takes in some form of customer requirements and outputs software (and perhaps support for that software). However, during that process, the development team does things - transformations of those requirements into something usable to design and build software, creation of designs, prototypes and simulations, production code, test code, supporting scripts, manual procedures (for testing, deployment...), user documentation, and more - any of which can have defects which would impact downstream activities that rely on that information. Quality assurance is concerned with not only how defects are found in these work products, but how those defects are prevented. Second, quality assurance is also interested in process quality - how well we are doing the work. Although the obvious thing here is the quality of the work products, it's also how long it takes to do the work (among other things).
Two of the tenets of Agile are to favor "individuals and interactions over processes and tools" and to favor "working software over comprehensive documentation". However, neither of these say that you shouldn't have a process or that you don't need any kind of documentation. If you're trying to implement a quality management system, it's likely that you are required to have some level of documentation that can be compared to the work that is actually done during auditing. I think that these Agile ideals are better expressed in a few of the concepts of lean software development - eliminate waste by removing delays in the process, reducing bureaucracy, and improving internal communication, amplify learning, and empowering the team to make decisions about how to best achieve the goals.
In addition to being responsible for internal auditing, a QA organization can also help support agility or lean software development by being responsible for helping to detect waste, find delays, and ensure that what is documented gives each development team sufficient leeway to implement process requirements (levied by customers, regulatory agencies, corporate mandates, etc.) in the best way for the individual project but still having some level of consistency across the organization to allow for people to transition between projects without having to relearn an entire new set of processes and methods on top of the technical learning curve.
However, based on some of your comments, it seems like the direction that this is going in is not Agile or lean. It's a fine line to walk on how detailed to make your process documentation. If it's too vague and gives each project team room to implement anything that they wanted to, leading to wide variations in process implementations (and therefore process quality and likely product quality) across the organization. If it's too specific and detailed, it's likely to add bureaucracy and comprehensive documentation would get in the way of interactions and working software. There needs to be balance between agility and the ability to obtain information about process quality (through measurements and some level of consistency).
See also:
