The AI Act in practice: what companies need to do concretely in 2026

The entry into force of the European AI regulation (EU AI Act) is no longer an abstract legal prospect, but a direct operational reality for every organization that develops, integrates, or procures software. Where public debate long focused on ethical principles and theoretical risk categories, the legal enforcement framework in 2026 forces hard technical and organizational choices. Organizations that apply artificial intelligence within HR processes, credit assessment, customer service, or automated document processing can no longer make do with informal experiments.

The overview on the AI Act timeline and its entry into force in 2026 contains a chronological overview of all formal deadlines and publication dates; this article shifts the perspective to the direct implementation practice within organizations. We cover how a realistic internal compliance program is set up, where the technical bottlenecks lie with logging and data quality, and how companies can cleanly define their role as deployer or provider without drowning in bureaucratic overhead.

1. Determine the division of roles: Provider versus Deployer

The first and most crucial step in any compliance audit under the AI Act is determining the organization's exact legal role for each individual system. The regulation draws a sharp distinction between the provider (provider) that develops an AI system or places it on the market under its own trade name, and the deployer (user) that deploys an existing system within its own professional activities. The obligations for providers are considerably heavier and include, among other things, conformity assessments, technical documentation, and CE markings.

Many Dutch companies assume that they are purely a deployer because they use external APIs from large technology vendors. That is a dangerous misconception. As soon as an organization fine-tunes an existing base model with specific company data, substantially changes the functionality, or integrates the model into a new product under its own brand, the organization can legally be promoted to provider. This is known as 'substantial modification.' The heavy provider obligations then shift in full to the party that carried out the modification.

Those who operate purely as a deployer are not exempt from obligations. Deployers must ensure correct use in accordance with the supplier's instructions, provide human oversight by qualified personnel, check input data for relevance and representativeness, and retain operational logs for as long as these fall under their control. Anyone who does not formally record their role division per use case in a register will run into immediate trouble during any inspection by supervisory authorities.

2. Risk classification of internal and external systems

The AI Act applies a risk-based approach with four levels: unacceptable risk (prohibited practices), high risk, specific transparency risk, and minimal risk. In 2026, the prohibition provisions are already in force. This means that systems for social scoring, manipulative subliminal influence, or real-time biometric identification in public spaces are categorically prohibited, with a few strictly defined law enforcement exceptions.

The biggest practical challenge lies in the category high-risk (High-Risk AI Systems). Annex III of the regulation designates specific domains that apply directly to Dutch businesses:

• Personnel management and HR: Software for automated resume screening, ranking applicants, performance evaluation, or automated decision-making on promotions and dismissals.
• Financial services and creditworthiness: Algorithms that determine the credit score of natural persons or make risk assessments for life and health insurance.
• Access to essential services: Assessment of admission to educational institutions or systems that determine whether someone is eligible for government benefits and subsidies.
• Critical infrastructure: AI components deployed in the security or control of energy, water, and transport networks.

For systems that fall under this category, organizations must be able to demonstrate before deployment that the system meets the requirements for risk management systems, data governance, technical documentation, logging, transparency, human oversight, and robustness. To understand how this Dutch oversight landscape is divided between the Autoriteit Persoonsgegevens and sectoral regulators, the dossier on AI oversight in the Netherlands and the role of regulators offers a detailed overview of powers and inspection frameworks.

3. Transparency requirements and AI literacy among employees

In addition to the heavy obligations for high-risk systems, Article 50 of the AI Act imposes direct transparency obligations on a much broader group of applications. An organization that deploys a chatbot or AI assistant for customer contact must inform end users in a clear and unambiguous manner that they are communicating with an artificially intelligent system, unless this is obvious from the context. In addition, synthetically generated audio, video, or text content relating to matters of public interest must be recognizably marked as artificially generated.

A frequently overlooked article with direct effect is Article 4 of the regulation: the obligation regarding AI literacy (AI literacy). Companies and institutions are legally required to ensure that their staff and other persons working with AI systems on their behalf have sufficient knowledge and skills. This obligation is proportionate to the context, the target group, and the potential risks of the technology deployed.

In practice, this means that a generic policy document is not enough. Employees who use AI tools for their daily work must be trained to recognize hallucinations, assess bias, and respect privacy and copyright boundaries. Organizations must be able to demonstrate that they offer targeted training and that employees understand when AI output needs to be critically reviewed by a human expert.

4. Data governance and bias mitigation in model selection

For high-risk systems, Article 10 of the AI Act sets extremely strict requirements for the datasets used for training, validation, and testing. These datasets must be subject to appropriate data governance and management practices. This includes examining in advance possible biases that could lead to discrimination or unfair outcomes, and taking appropriate measures to correct these biases.

Companies that procure ready-made language models or vision models through cloud providers run into a practical dilemma here: the underlying training data of large commercial models is rarely fully public. As a deployer, an organization cannot directly modify the supplier's training data. The deployer's responsibility therefore shifts to carefully auditing the input data and systematically evaluating the output data.

A robust data governance process requires organizations to structurally safeguard the following points:

• Representativeness: Testing whether the data fed to the model is representative of the specific target group to which the system is applied.
• Error detection and data hygiene: Checking for missing values, incorrect annotations, and statistical anomalies before data is included in automated decision-making chains.
• Bias audits: Periodically testing model outcomes for subgroup differences using standardized metrics such as disparate impact ratio or equalized odds.

To concretely embed these standards in quality management systems, more and more organizations are aligning with international frameworks; the article on AI standards and ISO norms such as ISO/IEC 42001 explains how these certifications serve as operational evidence during inspections.

5. Logging, traceability, and technical monitoring

High-risk AI systems must be technically designed to automatically keep logs throughout their entire life cycle. This logging functionality is not an optional debugging feature but a legal requirement to guarantee the traceability of the system's operation. The purpose is to allow incidents, substantial deviations, or discriminatory patterns to be reconstructed and analyzed after the fact by regulators.

The logging must, at a minimum, record the operational periods, the input data with which the system was invoked, the reference to the model version and system parameters used, and the generated outputs including confidence scores. For deployers, it specifically applies that they must retain these logs for a period appropriate to the intended purpose of the system, with a minimum term of six months, unless other sectoral legislation prescribes longer retention periods.

{
  "timestamp": "2026-08-15T14:22:01.412Z",
  "system_id": "hr-recruitment-ranker-v2",
  "model_version": "mistral-large-2407-instruct",
  "deployment_mode": "high_risk_annex_iii_4a",
  "input_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  "parameters": {
    "temperature": 0.0,
    "top_p": 1.0,
    "seed": 42
  },
  "metrics": {
    "latency_ms": 320,
    "confidence_score": 0.88,
    "human_override_triggered": false
  },
  "compliance_status": "verified_input_sanitized"
}

A crucial point of attention with logging is the interplay with the GDPR (Algemene Verordening Gegevensbescherming, AVG). Logging complete prompts and model executions can result in personal data or special categories of personal data being unintentionally stored long-term in log files. Organizations must apply pseudonymization, hashing, or automated PII masking (Personally Identifiable Information) to input streams before these are written to audit trails.

6. Human oversight and the 'human-in-the-loop' principle

The human oversight requirement (Human Oversight, Article 14) forces organizations to formally reconsider the relationship between human and machine. The law requires that the natural persons assigned to oversight fully understand the capabilities and limitations of the high-risk system. They must be able to actively resist the tendency toward 'automation bias' — blindly trusting automated outcomes.

There are three dominant forms of human oversight in production environments:

• Human-in-the-loop (HITL): Every individual decision requires active approval by a human operator before the action takes effect. This is the norm for decisions with significant legal or financial consequences.
• Human-on-the-loop (HOTL): The system acts autonomously within predefined parameters, but a human supervisor monitors the process in real time and always has the ability to intervene or stop the process.
• Human-in-command (HIC): The human oversees the entire operational framework, defines when the system may be deployed, and can disable the system at any time (the proverbial 'emergency stop button').

The rise of independently acting multi-agent systems puts heavy pressure on this oversight model. The background article on Agentic AI and autonomous decision-making loops goes deeper into the technical mechanisms with which autonomous software chains operate and why the risk of uncontrolled cascading errors specifically increases there. When agents independently execute API calls and manipulate databases, the AI Act requires hard deterministic boundaries to be built in that prevent a model from independently stepping outside its permitted mandate.

7. Vendor management, API gateways, and contractual agreements

Because most companies purchase AI capacity through external cloud providers and API vendors, vendor management has become a central pillar of AI compliance. An organization cannot contractually offload its legal responsibilities as a deployer onto a supplier. If a purchased AI system shows bias or fails in production, the deployer remains liable to the regulator and the citizens or employees involved.

To maintain control over model changes, downtime, and compliance parameters, modern software architectures increasingly make use of intermediary layers. The technical guide on the power and workings of an LLM API aggregator explains how a central gateway helps dynamically route requests, enforce logging, and prevent vendor lock-in. By placing a gateway between business applications and AI providers, organizations can apply centralized data masking, monitor response times, and switch directly to another model when a supplier changes its terms or model weights.

Contractually, companies must review their SLAs and procurement agreements with AI vendors on the following points:

• Detailed model cards and system information: The supplier must provide documented information about the model's capabilities, limitations, intended use scenarios, and known error margins.
• Change management: Obligation for the supplier to announce updates to model weights or system prompts in advance, so that the customer can run regression tests.
• Data usage rights: Explicit guarantees that submitted company prompts and customer data are not reused for retraining or fine-tuning the supplier's public base models.

8. Roadmap for the internal compliance audit in 2026

To prevent compliance from becoming an ad hoc reaction to external incidents, organizations must adopt a structured approach. The roadmap below outlines the necessary steps to set up a manageable and verifiable AI governance framework within the organization:

1. Inventory and shadow AI detection: Map all AI systems, API integrations, SaaS tools with built-in AI, and experimental projects within the organization. Block unauthorized tools that leak company data.
2. Risk and role qualification: Classify each inventoried system according to the AI Act categories (minimal, transparency, high, prohibited) and determine per use case whether the organization acts as deployer or as provider.
3. Gap analysis on high-risk systems: Test existing high-risk systems against the requirements for logging, data quality, human oversight, and technical documentation. Draw up concrete remediation plans for identified shortcomings.
4. Setting up the AI register: Create an internal register in which the purpose, owner, risk classification, data sources used, and oversight measures are clearly recorded for each model.
5. Rollout of AI literacy programs: Train employees and supervisors based on their specific responsibilities and record proof of participation to substantiate Article 4.
6. Continuous monitoring and incident response: Set up processes to detect drift in model behavior and define an escalation procedure for reporting serious incidents to the competent regulator.

9. Pitfalls and common misconceptions

In practice, organizations regularly fall into the same pitfalls when implementing the AI Act. The most common misconception is the assumption that compliance is purely a legal matter that can be resolved with a set of disclaimers and a privacy policy. The AI Act is fundamentally a technical-operational regulation; anyone without insight into model parameters, API logs, data conversions, and deterministic guardrails simply cannot deliver the required documentation.

A second pitfall is blindly trusting the marketing claims of software vendors who claim their product is '100% AI Act compliant.' Compliance is context-dependent: an HR tool may be technically flawlessly built, but if the deployer uses the tool without adequate human oversight or with non-representative input data, the deployer directly violates the law. Certification of the supplier never releases the user from its own duty of care.

Finally, excessive bureaucracy often leads to a false sense of security. Documents that are drawn up once and then disappear into a drawer do not protect against model drift, hallucinations, or operational errors. Successful compliance requires a pragmatic integration of legal frameworks into the organization's existing software development cycle (CI/CD) and IT management processes.