AI Act from Two Perspectives: The Auditor Asks, the Consultant Solves

I am in the fortunate position of seeing the same work from two sides. As a consultant, I work on AI Act projects: we classify systems, build an evidence base, and develop governance frameworks. As an auditor, I sit on the other side of the table, where the same work must be assessed: is the documentation sufficient, is the evidence sound, and does the solution work in practice?

The two roles require different perspectives, and that is precisely where their value lies. The auditor asks questions, while the consultant finds solutions. There are usually several viable answers to a good question; the task is to select the one that best fits the organisation concerned.

Why are auditors' questions important?

Over the course of a year, an auditor gains an inside view of many companies. They see where documentation repeatedly falls short, which arguments fail to stand up to scrutiny, and which solutions organisations can actually operate. They understand the available technical options, observe where the market is heading, and often encounter emerging technologies before they become widely adopted.

They also see which solutions prove sustainable: what still works a year after implementation and what comes to a halt at the first maintenance cycle or staffing change. This is not theoretical knowledge; it is operational and implementation experience. It is the basis from which the auditor asks questions.

Practical questions arising from the AI Act

In September, I gave a presentation entitled AI Act – and What It Means for a Company at CertUnion's 16th Auditor Forum for auditors of integrated management systems.

The most valuable part was not only the presentation itself, but also the questions raised by fellow professionals, especially those auditing IT organisations against ISO 9001 and ISO 27001. The discussion focused on issues that companies must address in practice:

• What can be accepted as evidence for a continuously learning model?
• How should a model provider based outside the European Union be managed?
• How does the NIS2 incident-reporting obligation intersect with Article 73 of the AI Act?
• How should model versions be documented so that, even two years later, it is possible to identify which model version made a particular decision, using which data and settings?
• What can be done when a developer uses a model through a cloud-based API and the logs are held by the provider?
• Can AI risk be incorporated into the existing ISO 27001 risk assessment, or is a separate register required?
• What does meaningful human oversight mean when a decision is made within seconds?

The final question also requires organisations to determine when a human-on-the-loop approach is sufficient and when the process must be slowed down enough to enable genuine human-in-the-loop oversight.

When does a deployer become a provider?

One of the most important and sensitive questions is when a company moves from the role of deployer to that of provider after integrating a model into its own product or development. The boundary is not defined by the technology alone. Relevant factors include who places the system on the market and under whose name, whether a substantial modification has been made, and whether the system's intended purpose has changed.

Under Article 25 of the AI Act, a change of role may trigger the full range of provider obligations. These may include the requirements set out in Articles 9–15, a quality management system, technical documentation, conformity assessment, and CE marking.

This role classification should be determined at the beginning of the development process, not immediately before the system is delivered.

There is no single answer to these questions that will work for every organisation. Several compliant solutions may exist, but the right one is always the solution that can be operated effectively within the company's particular development and operational environment.

AI Act compliance is a team effort

Compliance with the AI Act is a complex task and cannot be owned by a single profession. Legal interpretation is essential, but it does not create compliance on its own. The requirements must be translated into day-to-day operations: logging must be implemented, data quality and human oversight must be ensured, changes to learning models must be managed, and testing and decisions must be supported by auditable evidence.

These are also technical, IT, quality assurance, and governance tasks, particularly in a development environment. Sustainable results therefore require coordinated work across several areas of expertise.

This is precisely where Harvey's strength lies: lawyers, project managers, testing and quality assurance specialists, IT professionals, and experts in data management and management systems work together as one team. We can explain not only what the legislation requires, but also how those requirements can be met through multiple practical, proven solutions.