If someone asked you today to exhaustively list all the artificial intelligence systems active in your IT landscape (who operates them, on what data, with what level of autonomy), how long would it take you to answer with certainty?

That is exactly the question the AI Act asks. And it is precisely what an internal AI audit is designed to resolve. This is not just another compliance exercise : it's a structured governance process that starts by mapping what you have, so you can steer what you do.

This post gives you the method to do so, step by step.

In a nutshell

The AI Act requires every organization deploying AI systems to inventory, qualify, and document each use case, system by system. In this post, you will find a concrete diagnostic framework to launch your AI audit: the key steps, the right reflexes depending on your role (CIO, EA, PMO), and what this means in practice for your organization.

What is an internal AI audit, and why does the AI Act make it unavoidable?

An internal AI audit is a structured process of identification, qualification, and documentation of all artificial intelligence systems active in an organization's IT landscape - whether developed in-house, purchased as SaaS, or integrated through third-party solutions.

The AI Act has made it a regulatory requirement. The world's first dedicated legal framework for AI, it does not apply only to software vendors: any organization that uses an AI system in a professional context is considered a deployer - and therefore falls directly within its scope. Its central logic is one of proportionality: requirements are calibrated according to the potential risk of each use case, system by system.

This is a portfolio logic - which means, first and foremost, knowing what your portfolio contains.

How to Ensure Compliance with the AI Act

Download the guide

Shadow AI: what your IT department doesn't see yet

Shadow AI refers to all AI use cases deployed within your organization without validation or inventory by the IT department. It takes hold through an accumulation of decentralized decisions: a SaaS tool adopted by a business unit, a generative AI API integrated by an external provider without an Architecture review. The result: active systems, mobilized data, influenced decisions - with no one holding an end-to-end picture.

This is not an isolated phenomenon. According to Flexera (2026), 70% of IT leaders estimate that business units purchase more cloud and SaaS applications than IT is actually aware of.

From a regulatory standpoint, every unrecorded tool represents an exposure that is unevaluated, undocumented, and indefensible. An HR scoring tool purchased as SaaS by the HR department without going through IT constitutes, under Annex III of the AI Act, a high-risk system: unqualified, unsupervised, undocumented. If control authorities were to identify it, good faith would not be enough to cover the absence of a structured approach.

What you cannot see cannot be governed. And what you cannot govern, you cannot defend.

To get your concrete AI Act compliance checklist and your step-by-step action plan, download our guide.

Provider, deployer, or both? What the AI Act concretely expects from you

The AI Act distinguishes three regulatory roles:

• The provider, who develops or places an AI system on the market

• The deployer, who uses it in a professional context, including via a third-party SaaS tool

• The importer or distributor, who commercializes solutions of non-EU origin

IT departments frequently hold all three roles simultaneously: acting as provider when developing their own tools in-house, as deployer when integrating third-party solutions into the IT landscape, and as importer or distributor when redistributing internally models developed outside the EU - which is the case for the vast majority of large language models.

This overlap has a direct consequence: the IT department cannot delegate its AI Act compliance to its vendors. Even when purchasing a third-party solution, it remains responsible for the use it makes of it within its own context, from risk qualification to human oversight, through to technical documentation. This is often the stage where an expert or specialized consultant brings the most value: scoping the real perimeter before the work begins, and avoiding blind spots that are costly to correct later.

The provider is responsible for its system. The deployer is responsible for its deployment. This distinction radically changes the scope of your AI audit: in most cases, it is far broader than you would initially anticipate.

How to comprehensively map your AI systems

Mapping is the backbone of your AI audit. But it requires a prerequisite that is often overlooked: governance established upfront. Without an identified owner, without a clear mandate, a registry will be maintained by no one — and will become obsolete before it is ever useful.

Once this framework is in place, the goal is to cast the widest possible net, including in your artificial intelligence audit:

• Systems developed in-house by IT teams

• SaaS solutions incorporating AI features, whether adopted by IT or directly by business units

• AI capabilities embedded in third-party solutions (ERP, ATS, CRM), often silently activated during an update

• Systems currently in development and projects in the planning stage

Three sources to combine for a blind-spot-free inventory

No single source is sufficient to carry out your audit process successfully. The recommended methodology combines three complementary approaches:

• The IT audit: inventory of official systems, analysis of the existing application portfolio

• Business unit surveys: identification of decentralized use cases, SaaS tools adopted outside IT, AI initiatives launched without an Architecture review

• Application portfolio analysis: detection of AI features silently activated in solutions already in production

All three are necessary. The first source establishes the official perimeter. The second surfaces shadow AI. The third catches what the first two miss.

The variables to document for each identified system

For each inventoried system, a minimum set of variables must be documented:

• Description and objective of the system

• Precise use case: it is the use case that is qualified, not the software

• Data involved: nature, origin, sensitivity

• Decisions influenced or automated

• Designated owner

• Regulatory status: provider or deployer

• Deployment status: in production, in development, in planning

The classic pitfalls that distort the mapping exercise

• Do not inventory only "official" IT systems: everything business units have adopted on their own is part of the perimeter

• Do not overlook AI features embedded in your third-party solutions: ERP, ATS, CRM with scoring or decision-support capabilities are often the most exposed blind spots

• Do not conflate the software with the use case: the same tool can generate very different risk classifications across sectors and deployment contexts

• Do not produce a static registry without an update process: it will be obsolete by the next deployment or the next vendor update

How to qualify the risk level of each AI use case

Risk qualification is the analytical core of the AI audit. The AI Act structures this analysis into four levels, each carrying distinct requirements.

This is the good news for organizations embarking on this process: not all your initiatives carry the same regulatory weight. The challenge is knowing where each one stands - and that is precisely the purpose of this diagnostic phase.

The AI Act's graduated risk logic applied to your portfolio

Common cases for an IT department: HR, scoring, generative AI, third-party SaaS

In practice, the most common high-risk systems within an IT department fall under a few domains clearly identified by Annex III:

• HR and recruitment: automated CV screening, candidate scoring, performance evaluation

• Financial services: credit or insurance scoring

• Healthcare: AI-assisted medical diagnosis

• Conversational interfaces: customer support chatbot, conversational agent, internal AI assistant — all classified as "limited risk", with transparency obligations from August 2026

• Generative AI connected to a business tool via API: qualification must be conducted according to the decisions it actually influences

Documenting the qualification: a compliance element in its own right

The traceability of the qualification process is itself a compliance requirement. What matters is not only the outcome: it is the ability to demonstrate how you reached it, and by whom the decision was made.

Bear in mind:

• Document each qualification: why this system was classified in a given category, on what basis, by whom, and on what date

• Escalate ambiguous cases to the cross-functional steering committee, and if necessary to a specialized legal expert. A contestable qualification defended in good faith is worth more than an undocumented low classification

• Avoid deliberate under-qualification: supervisory authorities will look favorably on good faith in the process - not on evasion

The concrete steps to implement your AI Act audit

Essential prerequisites

Before getting into the detail of each step, a methodological prerequisite: treat your AI audit as a full IT project in its own right. Identified sponsor, constituted team, defined milestones, allocated budget - not an ad hoc working group that meets between two steering committees.

But bear in mind that these steps do not describe a project with an end date: they describe the construction of a permanent capability. The objective is not to "pass" the AI Act, but to steer your AI portfolio over time, with the same rigor as any other strategic asset in your IT landscape.

For standalone high-risk systems, the first four phases take an average of four to six months in a structured organization. The effectiveness of the process depends directly on how seriously it is framed upfront. This is also where internal adoption is decided: a well-scoped initiative from the outset generates less resistance and more durable results.

Building the team and establishing governance

This is the starting point - and the most frequent mistake is skipping it to go straight to mapping. A registry without an owner is maintained by no one.

The absolute priority: designate an AI compliance lead with a clear mandate, access to senior leadership, and cross-functional legitimacy. This role can be carried by the DPO, the CISO, a specialized consultant, or a dedicated team. What matters is that it is identified and resourced.

Around this person, a cross-functional steering committee must be constituted, bringing together at minimum: CIO, DPO, Legal, Security, and the business units using AI.

Three workstreams must be launched immediately and in parallel:

• Formalize an internal AI governance policy: scope, principles, validation process for new use cases

• Launch the team training plan: the AI literacy obligation (Art. 4) has been applicable since February 2025 - and the upskilling of collaborators directly conditions the effectiveness of change management

• Integrate AI compliance into existing governance bodies: Executive Committee, IT steering committees

From inventory to technical documentation

These three phases form the operational core of your AI audit:

• Mapping: exhaustive inventory using the three-source method detailed above, with the constitution of a living registry that can be presented to supervisory authorities

• Qualification: application of the AI Act framework system by system, documented traceability of each classification decision, escalation of ambiguous cases. This is where rigorous methodology makes all the difference: a well-documented qualification is a decisive advantage in the event of an audit

• Annex IV documentation: for each system classified as high risk, technical documentation is the cornerstone of your compliance

What must your Annex IV documentation cover?

• General description of the system and its objectives

• Training, testing, and validation data

• Performance metrics and known limitations

• Technical architecture and operating logic

• Security and robustness measures

• Residual risk assessment

One operational point to watch: any substantial modification to the system triggers a mandatory documentation update. Build this reflex into your delivery processes now - documentation that is current at deployment and outdated six months later does not protect you.

Risk management and human oversight

The risk management required by Article 9 of the AI Act is not a one-off assessment to be produced before go-live, but a continuous process throughout the lifecycle of each high-risk system. The quick win here is to build on your existing IT risk management processes rather than starting from scratch — automating certain monitoring and reporting tasks can significantly reduce the operational burden. The link between AI compliance and operational risk management is an opportunity for rationalization, not an additional constraint.

Human oversight is the other structural requirement of the AI Act for high-risk systems. It does not mean that a human must validate every decision produced by the system. The mechanism must enable a designated collaborator to understand, monitor, and correct the system when necessary.

Three conditions must be met:

• Integrate oversight by design, from the conception or purchase of the system

• Trace decisions and human interventions: traceability is a regulatory requirement, not an option

• Train internal auditors and designated supervisors: overseeing an AI system requires understanding its operating logic, its limitations, and its warning signals

Building continuous oversight

This is the step that determines whether your approach holds over time or erodes at the first change of scope.

Concretely, this means putting in place:

• AI compliance dashboards: registry coverage, documentation status, alerts on unqualified systems or systems with outdated documentation

• Regular portfolio reviews: at each new deployment, each substantial modification, each vendor change

• Integration of AI compliance into the lifecycle of every new IT project: a system deployed without prior qualification is a future problem waiting to happen

• Reporting to governance bodies: Executive Committee, board of directors where relevant

To access the complete AI Act compliance checklist and your concrete action plan, download our guide.

How to Ensure Compliance with the AI Act

Download the guide

Why a one-off AI audit is not enough?

A one-off AI audit is a necessary step, not the destination. AI Act compliance must not be treated as a closed project. That would be a methodological illusion. And it is precisely here that the real difference emerges between organizations that master their AI ecosystem and those that are overwhelmed by it.

An audit takes a snapshot, while your IT landscape keeps moving

The IT landscape evolves constantly: new SaaS tools adopted by business units, AI features activated automatically during a vendor update, agents deployed by external providers without IT notification. Every change is a potential blind spot if governance is not structured to absorb it.

What the AI Act actually requires is not an annual snapshot of your AI portfolio: it is a continuously maintained picture. For each system, the regulation requires linking agents to their architectural context, keeping responsibilities up to date, and updating technical documentation at every substantial modification. A static registry, however complete at the time of its production, is obsolete by the next deployment.

AI Act compliance is not a state you reach. It is a capability you maintain.

From one-off audit to continuously managed AI portfolio

This is the true paradigm shift the AI Act demands. Static documentary approaches (spreadsheets, one-off audits, annual registries) have a structural limitation: they inventory without connecting. They do not link AI systems to their architectural context, their data flows, their actual owners, their business processes.

The result: documentation that is formally present, and operationally useless.

What needs to be built is a living AI portfolio, not an audit repeated every year. An AI governance roadmap, not a static registry. A reference framework that connects each agent to its Architecture, its data, its owners, its business value — and that automatically adapts to every evolution in scope, without starting from scratch.

The link with existing IT governance is structural here. Organizations that had already structured their application portfolio and IT risk management before the AI Act are six to twelve months ahead.

For others, both workstreams must be run in parallel. The AI Act acts as a revealer: it brings to light governance gaps that existed long before it - and that should have been addressed regardless. The ROI of this investment extends well beyond regulatory requirements: strategic alignment, portfolio management, operational risk control, and productivity gains across IT decision-making processes.

A well-structured AI governance today is not merely a response to the AI Act. It is a lasting competitive advantage.

What does this look like with Smoteo?

Smoteo is designed precisely for this transition: from a one-off audit to a continuously managed AI portfolio. The platform structures everything the AI Act requires (and that your organization must master over time) into a unified reference framework.

• The Usage Registry continuously centralizes all active AI tools and initiatives by department: application context, data flows, designated owners, qualified risk level

• The AI Value Stream Map visually maps each AI agent across the business and IT ecosystem: which domains it covers, which data it consumes, which business capabilities it touches

• Epic Cards structure each AI initiative from its origin (objectives, dependencies, data, risks, business value) and directly constitute the documentary base required by Annex IV - without re-entry, without last-minute reconstruction

• The Smoteo meta-model connects strategy, Architecture, portfolio, and delivery in a unified view, for compliance management integrated into the CIO's daily operations

The result is clear: over 80 % coverage of applications, processes, and agents in the mapping, and a 30 % reduction in the risk of non-compliance before go-live.

From AI audit to lasting governance: a paradigm shift

The AI Act is not a constraint that appeared out of nowhere. It is the regulatory formalization of a problem that many CIOs, DPOs, and CISOs already know intimately: artificial intelligence is being deployed across organizations faster than the capacity to govern it.

A rigorous internal AI audit is the first step toward regaining control. But it is only the beginning. The organizations that will emerge stronger from this regulatory phase will not be those that produced the most complete registry before the deadline. They will be those that understood that compliance is a pretext, and governance the real stakes — those that transformed a regulatory obligation into durable infrastructure: a living AI portfolio, continuously managed, aligned with strategy, and defensible before regulators.

Ready to move from a one-off audit to a structured, continuously managed AI portfolio? Smoteo centralizes the usage registry, agent mapping, and technical documentation in a single reference framework, kept up to date in real time. Request a demo.

Practical Guide

How to Ensure Compliance with the AI Act

Deadline schedule, risk levels, and a comprehensive checklist to keep your project on track

Download the guide

Download the guide