The AI Act has entered its operational phase. For companies, the issue is no longer simply understanding the regulation, but turning its requirements into manageable workstreams, with identified owners, retained evidence and documented decisions.
AI Act compliance involves the IT Department, business teams, the Procurement Department, HR, Legal, Compliance, Cybersecurity and Data Protection. It requires organisations to know which systems they use, assess their risk level, verify their legal role and manage their suppliers.
Here are the ten priority workstreams to launch in order to build a realistic roadmap for 2026.
Where should a company start to comply with the AI Act?
To comply with the AI Act, a company should first map its uses of artificial intelligence, identify the relevant owners, assess the risks and identify prohibited practices or uses subject to transparency obligations. It can then create an AI Registry, address priority systems and organise oversight, documentation, training and supplier monitoring.
What is changing for companies in 2026?
The AI Act timetable was adjusted by Regulation (EU) 2026/1744, known as the Digital Omnibus on AI. The official version of the text is available through EUR-Lex. The applicable deadlines vary depending on the category of system and the organisation’s role.
For high-risk systems covered by Annex III, the main obligations are scheduled to apply from 2 December 2027. High-risk systems integrated into regulated products covered by Annex I will be concerned from 2 August 2028, subject to the applicable transitional provisions. The consolidated version of the regulation, updated on 27 July 2026, should remain the reference point for checking the timetable applicable to each system.
Since 2 August 2026, the transparency obligations set out in Article 50 have applied to the relevant systems. People must notably be informed when they interact directly with certain AI systems. Specific rules also apply to the marking of certain content generated or manipulated by AI.
The European Commission has published guidelines on the Article 50 transparency obligations, as well as a FAQ on their implementation. A specific deadline of 2 December 2026 applies to certain systems already placed on the market before 2 August 2026, regarding the obligations to mark and detect content generated or manipulated by AI.
This does not mean that every company must address every system at the same pace. It primarily means that organisations must know their scope, assess the applicable deadlines and retain the decisions that explain their chosen priorities.
The cost of inaction
Article 99 of the AI Act provides for administrative fines of up to €35 million or 7% of total worldwide annual turnover, whichever is higher, for breaches of the prohibited practices. For other breaches relating to the obligations of operators or notified bodies, the maximum can reach €15 million or 3% of total worldwide annual turnover. Supplying incorrect, incomplete or misleading information may result in a maximum fine of €7.5 million or 1% of worldwide turnover.
These amounts are regulatory ceilings, not an automatic estimate of the penalty applicable to every situation. The penalty must remain effective, proportionate and dissuasive. Other legal frameworks may also apply depending on the facts, including the GDPR where personal data is processed.
For a large group, this level of exposure justifies an executive sponsor, an identified budget and governance that does not rely solely on an IT initiative.
The 10 workstreams to launch
An effective roadmap does not consist in addressing the regulation’s obligations in article order. It starts with the workstreams that provide visibility, then focuses resources on the most sensitive systems.
Workstream 1: establish cross-functional AI governance
The first workstream is to decide who owns AI Act compliance and how decisions are made. In a large group, AI systems are spread across business applications, HR tools, procurement solutions, data projects, SaaS software and products developed internally. Governance limited to the IT Department will not cover all uses.
The framework must set out the responsibilities of the executive sponsor, the IT Department, business teams, the Procurement Department, HR, Legal, the Data Protection Officer, Compliance and Cybersecurity. It must also define the cases that require approval before an experiment or production deployment.
To avoid creating a parallel framework, AI governance can build on the standards already used by the organisation. ISO/IEC 42001:2023 provides a framework for an artificial intelligence management system. The NIST AI RMF offers a structured approach based on four functions: Govern, Map, Measure and Manage. These frameworks can inform the organisation without replacing the AI Act’s legal requirements.
Deliverable: an AI governance charter, a RACI matrix, a committee calendar and a process for approving new uses.
Owner: IT Department or Chief Data Officer, with an executive sponsor.
Anti-pattern: creating an AI committee without decision-making authority, a budget or a clear connection to the risk, security or compliance committees.
Workstream 2: map all AI systems and uses
An organisation cannot assess a risk it has not identified. The first inventory is often limited to officially declared AI projects. The second pass must cover functions already enabled in the CRM, ticketing tool, office suite, ATS, customer relationship tools and supplier management solutions.
The gap often comes from the scope. Some AI functions have been enabled by a supplier without a central project, IT approval or clearly designated owner. The inventory must therefore involve IT teams, business functions, Procurement and application owners.
For each system, the organisation must document its purpose, business owner, supplier, data used, users concerned, processing location, interfaces with other applications and any decision that may be influenced by the AI system. It must also identify general-purpose AI models integrated into third-party applications.
Deliverable: a qualified inventory of AI systems and uses, with an identified owner for each entry.
Owner: IT Department, with input from user departments and Procurement.
Anti-pattern: assigning the inventory solely to the IT Department. This approach misses AI functions enabled by default in software already used by teams.
Workstream 3: assess risks and the organisation’s legal role
Risk classification is the bridge between the inventory and the action plan. Each system must be assessed according to its actual purpose, area of use, people concerned and potential impact on their rights or safety.
Two questions must be answered: what is the system’s risk level and what is the organisation’s legal role? Article 3 distinguishes between the provider, which develops or has a system developed and places it on the market or puts it into service under its own name or trademark, and the deployer, which uses a system under its own authority.
The risk of being reclassified as a provider
A group that places its name or trademark on a high-risk system, substantially modifies it or changes its purpose in a way that brings it into the high-risk category may become a provider under Article 25. It would then assume more than the obligations of a deployer. It may have to take responsibility for documentation, risk management and conformity assessment obligations.
This risk may concern internal assistants retrained on group data, copilots developed under an in-house brand and systems whose purpose has been changed compared with the provider’s documentation.
Recruitment, candidate screening, employee assessment and access-to-work tools must be reviewed carefully. The European Commission identifies tools used for employment, worker management and access to self-employment among the use cases that require analysis.
Deliverable: a two-dimensional qualification grid, a register of classification decisions and a remediation plan for sensitive uses.
Owner: Compliance or Legal, with the IT Department and business teams.
Anti-pattern: classifying a tool solely on the basis of its commercial name. Risk depends on the purpose and context of use, not on labels such as “assistant”, “scoring” or “copilot”.
Workstream 4: create a usable AI Registry
The internal AI Registry is not just a tracking spreadsheet. It should become the access point for the information needed to understand, control and audit the organisation’s AI systems.
For each system, the registry should link to the supplier documentation, contract, impact assessment, risk classification, approval decisions, responsible people, test results, incidents and corrective actions. It should be connected to the existing processes for asset, supplier, risk and change management.
The internal registry must be distinguished from the European database provided for by the AI Act. Registration requirements vary depending on the type of system, the organisation’s role and the relevant sector. The internal registry answers a management question: which AI systems do we use, for what purpose, with which data and under whose responsibility?
To review the definitions and risk categories, also consult our general guide to the AI Act.
Deliverable: an internal AI systems registry connected to compliance documents and control evidence.
Owner: IT Department or AI governance lead.
Anti-pattern: maintaining a registry separately from the asset, procurement and change-management repositories. It becomes outdated as soon as tools, suppliers or owners change.
Workstream 5: build compliance files for high-risk systems
High-risk systems must be treated as full compliance workstreams. The file should bring together the information needed to understand the system’s purpose, limitations, conditions of use and related controls.
It should specify the provider’s intended use, the data involved, oversight arrangements, available logs, human intervention rules, incident procedures and the information required by the professional user.
Business example: a candidate-scoring tool
An HR Department uses a tool that ranks CVs according to criteria configured by the provider. The provider alone is not enough to secure the process. The company must identify the system owner, document the role of the score in the decision, check that a recruiter can challenge or correct the result, organise traceability and retain useful information about how the tool operates.
Human oversight must be tangible. The designated person must understand the system, know its limitations, have access to the necessary information and be empowered to request a review, correct a result or suspend the tool’s use.
Deliverable: a compliance file for each high-risk system, together with a list of missing elements and a remediation plan.
Owner: system owner, under the supervision of IT or Compliance.
Anti-pattern: assuming that the supplier’s file is sufficient. The deployer must also document its own use, teams, controls and decisions.
Workstream 6: distinguish between a DPIA and a fundamental rights impact assessment
The AI Act does not replace the GDPR. The two frameworks must be considered together when an AI system processes personal data, but they do not create the same deliverables.
A DPIA, or data protection impact assessment, falls under Article 35 of the GDPR. It applies when processing is likely to result in a high risk to the rights and freedoms of individuals.
The fundamental rights impact assessment provided for by Article 27 of the AI Act does not apply to every private deployer. Its scope depends in particular on the organisation’s status, the service provided and the system concerned. A DPIA may therefore be necessary even where an assessment under Article 27 is not automatically required.
The two assessments can be coordinated when their scopes overlap, but they must remain clearly identified as separate documents.
Deliverable: a DPIA where required by the GDPR, a fundamental rights impact assessment where Article 27 applies, a fundamental rights risk matrix and a bias-control plan.
Owner: Data Protection Officer for the DPIA; Compliance or Legal for the AI Act framework, with business and data teams.
Anti-pattern: producing a generic document called an “AI impact assessment” without specifying the applicable legislation, accountable party, people concerned and risk-reduction measures.
Workstream 7: organise human oversight, traceability and incident management
Human oversight cannot be reduced to the theoretical presence of a user in the process. The person responsible for oversight must understand the system, know its limitations and have the authority to correct, suspend or stop its use.
Consider an AI fraud-detection system. If the system automatically blocks a transaction, the organisation must determine who can review the alert, within what timeframe, with which information and under which appeal procedure. It must also monitor false positives, population-level bias and changes in performance.
The framework must specify the events to monitor, alert thresholds, escalation rules and log-retention conditions. Logs must be accessible to the people controlling the system, while complying with security, confidentiality and data-minimisation requirements.
Deliverable: a human-oversight procedure, an incident log, log-retention rules and an alert-monitoring dashboard.
Owner: IT Department or system owner, with the relevant business function.
Anti-pattern: appointing an overseer without allocating time, providing access to system data or granting real authority to suspend the system.
Workstream 8: ensure transparency and user information requirements are met
Transparency obligations require a review of interfaces, user journeys and generated content. A customer-service chatbot is a useful example: where the obligation applies, users must know that they are interacting with AI and must know how to obtain support from a human contact when necessary.
The workstream should cover chatbots, conversational assistants, text-generation tools, summarisation features, visual content and recommendation interfaces. The wording to display, its location and the point at which it appears must be documented.
Transparency cannot be reduced to a general sentence in the terms of use. It must be checked across the person’s actual user journey: login screen, conversation window, generated result, external publication or decision influenced by the system.
Deliverable: a transparency-obligations matrix, approved wording, content-signalling rules and an update process.
Owner: Product, IT or Legal, depending on the system.
Anti-pattern: adding a general notice to the terms of use without checking the actual journey in which the user interacts with the system.
Workstream 9: deploy AI literacy and an AI Champions network
Training must be adapted to each person’s role. A business user does not need the same level of information as a developer, software buyer, HR manager or person responsible for overseeing a high-risk system.
The programme should explain permitted uses, data that must not be submitted to a tool, approval rules, incident-reporting procedures and the limitations of generated outputs. For exposed populations, training should also cover bias, human oversight, traceability and the rights of affected people.
AI Champions can act as relays across functions and countries. They report uses, direct teams to the approval process, share the rules and identify situations requiring the involvement of IT, Legal, the Data Protection Officer or Procurement. They do not replace those functions.
Deliverable: a role-based training programme, a skills matrix and an AI Champions network.
Owner: HR or Transformation Department.
Anti-pattern: creating an AI Champions network without dedicated time, management sponsorship or a channel for reporting uses.
Workstream 10: secure AI suppliers, Procurement and contracts
Procurement teams must integrate the AI Act into supplier approval, tendering, negotiation, renewal and exit processes. The contract must make clear who provides the documentation, who reports incidents, who controls model changes and who assumes each regulatory obligation.
Consider an AI-enhanced sourcing tool. The Procurement Department must check exactly what the score produced by the tool represents, which data is used, how explanations can be accessed, whether a recommendation can be challenged and how the supplier will be controlled.
The supplier questionnaire should cover the system’s classification, purpose, data used, subcontractors, processing location, security measures, logs, human oversight and incident-notification procedure.
To explore this workstream further, consult the article “AI-enhanced procurement: how AI is reshaping the Source-to-Pay cycle”, which presents the role of AI in the procurement of professional services.
Deliverable: an AI supplier questionnaire, contractual clauses, a due-diligence grid and a review process before supplier approval or renewal.
Owner: Procurement Department, with Legal, IT, Security and the user business function.
Anti-pattern: requesting a general compliance statement without obtaining the system documentation, allocation of responsibilities and incident-notification conditions.
How should actions be prioritised over 30, 60 and 90 days?
The 30/60/90-day plan does not replace the regulatory deadlines. It provides an operating sequence, makes decisions visible and prevents the most sensitive systems from remaining without an owner or compliance file.
| Period | Priority actions | Expected deliverables | Functions involved |
|---|---|---|---|
Days 1 to 30 | Appoint a sponsor, establish governance, conduct an initial inventory, identify prohibited practices and audit interfaces covered by transparency obligations | Governance charter, initial mapping, list of priority uses and initial decisions | IT, business teams, Legal, Compliance, Procurement, HR, Data Protection |
Days 31 to 60 | Formalise classification, build the AI Registry, question suppliers and launch priority impact assessments | Qualified registry, supplier questionnaires, initial remediation list and assigned owners | IT, Compliance, Legal, Data Protection, Procurement, Data teams |
Days 61 to 90 | Prepare high-risk compliance files, formalise human oversight, define log-retention rules, structure incident management and train exposed teams | Compliance files, control procedures, management dashboard and training programme | IT, business teams, HR, Compliance, Security, Procurement |
An IT Department can start with systems that influence decisions about individuals, systems that interact directly with the public and systems provided by suppliers whose documentation is incomplete. This prioritisation makes it possible to address first the situations with the greatest operational, social or regulatory consequences.
Three concepts that should not be confused
The European AI Office
The AI Office is a European Commission structure. It is involved in particular with general-purpose AI models and certain associated systems. National competent authorities supervise other systems according to their respective remit.
A company therefore does not need to create an internal department called an AI Office to be compliant. It does, however, need to organise regulatory monitoring, follow the guidelines and retain the decisions explaining how it applies the regulation.
The internal AI Registry
The AI Registry is the organisation’s management register. It brings together systems, owners, risk levels, completed controls and available evidence. It answers a straightforward question: which AI systems do we use, for what purpose, with which data and under whose responsibility?
AI Champions
AI Champions are internal relays. They make governance accessible to the teams that actually use AI and facilitate the reporting of undeclared uses. They do not replace the Data Protection Officer, Compliance, IT or the system owner.
Moving from the plan to execution
The ten workstreams require skills that are not always available internally at the same time: AI governance, regulatory compliance, data, cybersecurity, procurement and transformation.
If your organisation needs to define or deliver an AI Act roadmap, you can discuss your expertise needs with LittleBig Connection. The objective is to identify the required skills based on the systems, countries, suppliers and functions involved.
Key takeaways
Becoming compliant with the AI Act does not mean drafting a general policy and placing it in a document repository. The process must produce evidence, assign responsibilities and create controls that teams can actually use.
The ten priority workstreams are governance, mapping, risk classification, the AI Registry, high-risk compliance files, impact assessments, oversight, transparency, training and supplier management. Implementation can begin immediately, even where the deadline applicable to certain systems is set for 2027 or 2028.
Applicable rules may vary depending on the organisation’s role, the type of system, the sector and the use case. Each situation should be checked with the relevant Legal, Compliance, IT, HR, Procurement or Data Protection teams.
