Elba and the EU AI Act

The EU AI Act is in force. Most of its provisions apply from 2 August 2026, including the transparency requirements that matter directly to interactive and generative AI systems. The principal requirements for Annex III high-risk systems now follow in December 2027, with certain product-related high-risk systems following in August 2028.

It has not been an entirely restful journey.

GDPR was difficult, but it had the considerable advantage of remaining broadly stationary while you were reading it. The EU AI Act arrived while the technology, terminology, guidance, standards and legislation were all continuing to develop around it. Ah yes - the good days when having a nap after lunch did not mean you had missed the latest quantum leap in AI...

Still, we have arrived.

At Kolsetu, we have defined Elba’s intended purpose, assessed its standard uses against the prohibited and high-risk boundaries, documented the roles of the parties, established review triggers, implemented platform-level transparency controls and connected the whole structure to our privacy, security and AI-management systems.

This article explains what the EU AI Act is trying to achieve, how it applies to an AI voice and communications platform, and where Elba stands today. Not as a slogan. As a documented compliance position.

What the EU AI Act is trying to achieve

The central idea is straightforward: the rules applying to an AI system should reflect what the system does and the risks its use creates.

The usual explanation divides AI into four levels: unacceptable risk, high risk, limited risk and minimal risk. That is useful shorthand, although the Act itself is more complicated. It contains prohibited practices, an extensive regime for high-risk systems, transparency duties for interactive and generative systems, separate rules for general-purpose AI models and broader obligations such as AI literacy.

Certain practices are prohibited outright. These include specified forms of harmful manipulation or exploitation, social scoring, biometric categorisation based on sensitive characteristics and particular uses of remote biometric identification.

High-risk systems are primarily identified through Article 6 and the use cases listed in Annex III. These include certain systems used in biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration and the administration of justice.

Providers of high-risk systems face extensive requirements covering risk management, data governance, technical documentation, record keeping, transparency, human oversight, accuracy, robustness, cybersecurity, conformity assessment and post-market monitoring.

Other systems may not be high-risk but still carry transparency duties. Interactive AI must tell people they are interacting with an AI system unless that is obvious in the circumstances. Providers of systems generating synthetic content must, where Article 50(2) applies, make the output machine-readable and detectable as artificially generated or manipulated.

The Act therefore does not merely ask whether something contains AI. It asks what it does, who provides it, who uses it, which decisions it affects and what happens when it goes wrong.

That version takes longer to put on a slide, but it is considerably more useful.

Provider, deployer and intended purpose

The distinction between provider and deployer determines who is responsible for what.

• A provider develops an AI system, or has it developed, and places it on the market or puts it into service under its own name or trademark.
• A deployer uses an AI system under its authority in a professional context.

Kolsetu is the provider of Elba. We develop and control the platform, define its standard intended purpose, establish its safeguards and place it on the market under the Elba name.

Enterprise customers will ordinarily be deployers when they configure and use Elba for their own operations. However, the legal role is not fixed permanently by the heading in the contract.

Under Article 25, another party may assume provider obligations where it places an existing system on the market under its own name or trademark, makes a substantial modification, or changes its intended purpose in a way that causes it to become high-risk.

A customer does not automatically become a provider merely by configuring a workflow. Equally, calling itself a deployer does not preserve that role if it fundamentally changes what the system is intended to do.

Our governance model therefore defines Elba’s intended purpose, approved use categories, excluded uses and review triggers. Routine deployments within those boundaries remain covered by the platform assessment. A materially different deployment receives a separate review before it is approved.

Much of compliance consists of documenting things that become obvious immediately after somebody has done the work.

How we classified Elba

Kolsetu has completed and documented a formal EU AI Act Classification and Risk Assessment for Elba. The assessment covers the platform, its standard deployment models and the controls used to prevent ordinary deployments from drifting into prohibited or high-risk use. Rather than applying one permanent label to every conceivable configuration, it uses a detailed platform assessment, reusable use-category baselines and trigger-based review for exceptional or materially different deployments.

Elba’s controlled intended purpose covers communication, workflow orchestration, information retrieval, structured data collection, case creation, booking, document intake, billing support, customer service and commercial dispatch.

Within that purpose, Elba supports processes and human decision-making. It is not intended to autonomously determine legal rights, employment outcomes, creditworthiness, access to public services or comparable consequential matters.

We assessed Elba and its ordinary uses against the prohibited practices under Article 5 and the high-risk categories under Article 6 and Annex III.

Our current conclusion is that ordinary customer-support, booking, information-retrieval, claims-intake, billing-support, document-intake and commercial-dispatch deployments fall outside Annex III and are not high-risk systems.

That conclusion has limits: an agent that gathers information and passes a case to a qualified human decision-maker is not the same as a system autonomously deciding whether somebody receives a loan, a job, a public benefit or medical treatment.

We therefore require a separate review where a proposed use introduces a material trigger, including biometric categorisation, emotion recognition, safety functions, autonomous eligibility decisions, employment decisions, creditworthiness assessment or another potential Annex III use.

Where a use is prohibited, it is blocked or discontinued. Where it may be high-risk, the deployment does not proceed under the standard classification.

The assessment is linked to onboarding, product controls, contractual restrictions and change management. It was not created solely so that procurement could receive a PDF with the correct title.

The AI impact assessment

Legal classification is essential, but it does not answer every question about how an AI system may affect people or organisations. We therefore also applied an AI impact-assessment process aligned with our implementation of ISO/IEC 42001.

The assessment considers Elba’s intended and reasonably foreseeable use, the people who may be affected, the degree of human oversight, potential impacts on rights and access to services, risks arising from inaccurate outputs, accessibility, vulnerable persons, misuse, dependency, security, privacy and operational failure.

This gives us a broader view than legal classification alone: a system may remain outside Annex III and still require meaningful safeguards. “Not high-risk under the EU AI Act” is a classification result, it is not a declaration that nothing unfortunate could ever happen. The findings feed into the platform risk assessment, approved-use boundaries, design controls, customer instructions and the ISO 27001 risk-treatment process. Material changes can trigger reassessment.

An impact assessment that is completed, admired and then disconnected from engineering is mostly an unusually formal diary entry.

The governance behind the classification

Our EU AI Act position is not built around one assessment. We maintain an interconnected governance framework that includes the Artificial Intelligence and Machine Learning Policy, AI Development Work Instruction, AI Tool Register, EU AI Act Classification and Risk Assessment, ISO/IEC 42001-aligned impact assessment, Article 50 Compliance Position, Elba Data Protection Impact Assessment, NIST AI Risk Management Framework maturity assessment, AI literacy records, contractual controls and supporting development and delivery evidence.

Did we (okay, to be fully transparent: it was not "we", it was "me") overdo it? Possibly. At some point, adding another framework began to feel like ordering another round of Jägermeister at 1 a.m. But the overlap was deliberate: each framework covers a slightly different angle, and together they reduce the chance of a material risk or obligation slipping through the cracks. The result is a functioning governance system rather than a headache and several unanswered messages.

The AI Tool Register is the authoritative record of the AI systems and models used by Kolsetu. It records their purpose, deployment context, Kolsetu’s role and relevant governance information. Our policy requires the register to remain current rather than becoming an archaeological record of models we used six months ago.

The Elba Data Protection Impact Assessment addresses the personal-data risks associated with voice data, transcripts, identity information and case data. It remains separate from the AI classification and impact assessment because GDPR and the AI Act ask different questions.

We have also completed a NIST AI Risk Management Framework maturity assessment across the Govern, Map, Measure and Manage functions. The framework is voluntary, but it helps establish whether governance is connected to actual systems, owners, controls, evidence and decisions.

Our governance model connects the AI classification and impact assessment to the DPIA, information-security risk treatment, supplier controls, incident processes, development requirements and customer documentation.

ISO/IEC 42001: implemented, not (yet) certified

We implemented the structure and requirements of ISO/IEC 42001 as an internal AI management system. This includes governance roles, policy, objectives, risk and impact assessment, lifecycle controls, supplier and model oversight, documented operating procedures, performance evaluation, corrective action and continual improvement.

We are not currently certified to ISO/IEC 42001 and do not claim to be. Certification would require an external audit by an appropriately accredited certification body. Implementing the management system and holding a certificate are related, but they are not interchangeable statements. The ISO/IEC 42001 standard is implemented and used as the management framework for our AI governance.

The AI Act does not require ISO/IEC 42001 certification. The value of the standard is that it makes governance repeatable, auditable and capable of surviving changes in personnel, models and guidance. The certificate can come later. The operating model had to come first.

AI literacy

Article 4 requires providers and deployers to take measures to ensure a sufficient level of AI literacy among personnel and others dealing with AI systems on their behalf. The appropriate level depends on their technical knowledge, experience, role, training and the context in which the system is used. The requirement has applied since February 2025.

AI literacy is not something to schedule after the product team has finished doing the interesting work. A developer, implementation engineer, salesperson and compliance specialist do not require identical training. They do, however, need enough knowledge to recognise when a proposed use has crossed a boundary.

We have a documented AI literacy programme and training records covering the benefits, limitations and risks of AI, responsible use, role-specific obligations, escalation routes and the controls applying to Elba and our other AI tools. That does not mean I sat down our Head of AI, CEO and CTO and lectured them on the dos and don’ts of artificial intelligence. Their technical knowledge goes considerably deeper than mine, and any attempt to do so would probably have ended in hysterical laughter.

My job was different: to make sure they understood exactly where the legal and governance boundaries sit, and how far we can responsibly push them. I used a small trick I learned years ago and have since perfected: ask apparently stupid questions and occasionally introduce a deliberate mistake. If someone spots it, corrects it and can explain precisely why the AI apple is not an orange, you have tested both their understanding and the limits of the system.

They may leave the conversation thinking you are a daft noodle. You leave knowing the i’s have been dotted and the t’s crossed.

Article 50: telling people that Elba is AI

Article 50(1) requires providers of systems intended to interact directly with natural persons to ensure that people are informed they are interacting with AI, unless this is obvious in the circumstances. The requirement applies from 2 August 2026.

For an AI voice agent answering a customer-service line, we do not rely on the argument that the caller really should have noticed. We have implemented AI disclosure as a mandatory platform-level control. Every externally exposed Elba interaction must include an appropriate disclosure. The wording can be adapted to the customer, language and channel, but the disclosure itself cannot simply be removed through normal configuration.

Our Article 50 Compliance Position documents the disclosure control, publish-time validation, testing requirements, ownership and evidence. The control applies across deployments rather than only where somebody has successfully identified the user’s location and selected the right legal toggle. A single global standard is easier to test and considerably harder to forget.

Short disclaimer: the AI disclosure is not a privacy notice. It merely tells the person that the interaction involves AI. It does not explain what personal data is collected, why it is processed or how long it is retained.

Article 50: marking synthetic content

Article 50(2) applies to providers of systems generating synthetic audio, image, video or text content. The output must be marked in a machine-readable format and detectable as artificially generated or manipulated. This is relevant to Elba because the platform generates synthetic voice and text.

Kolsetu signed Section 1 of the EU Code of Practice on Transparency of AI-Generated Content. That section concerns the marking and detection of AI-generated and manipulated content. We did not sign the deployer section because Kolsetu does not currently deploy Elba to publish covered deepfakes or public-interest text. Customers whose use triggers Article 50(4) remain responsible for their own deployer obligations.

The Code is voluntary. The Commission and AI Board have concluded that it adequately covers the relevant Article 50 obligations and provides an EU-wide route for demonstrating compliance, although adherence is not conclusive evidence of compliance.

Signing the Code matters, but it is not itself the technical implementation. For synthetic audio, we must establish whether a marking mechanism remains effective after generation, processing, encoding and transmission through the telephony pipeline. For text, we must implement or verify an appropriate machine-readable mechanism and corresponding detection capability. Upstream vendor functionality may form part of the solution, but reliance on a vendor does not make our responsibility disappear.

Our implementation programme covers the selected mechanisms, vendor evidence, technical testing, telephony-pipeline resilience, detection capability, documented limitations, ownership and sign-off. It turns out that “add a watermark” is a much shorter sentence than it is an engineering task. I suspect this is possibly one of the many reasons our development team loves me so much...

Registration: when it is and is not required

There is no general EU database registration obligation for every non-high-risk AI system.

Providers of high-risk systems listed in Annex III generally have registration duties under Article 49. Registration is also required where a system falls within an Annex III use case but the provider concludes that it is not high-risk because the Article 6(3) conditions apply. In that situation, the provider must document the assessment and register the system.

Elba’s ordinary approved uses are assessed as outside Annex III, rather than as Annex III systems relying on the Article 6(3) exception. Kolsetu therefore does not register the platform or every routine deployment merely because Elba uses AI. Where a proposed use falls within Annex III and we conclude that Article 6(3) applies, the required deployment-specific assessment and registration would be completed before the system is placed on the market or put into service for that use.

Registration follows the applicable classification route. It is not a general badge of good behaviour. I initially had the rather sweet-summer-child idea that we should simply register Elba as high-risk because transparency is king. The problem was that high-risk classification is not an honesty award. It would have meant voluntarily presenting Elba as something it is not and taking on a substantial body of unnecessary documentation, conformity and lifecycle obligations. The invoice would not have been for clicking “register”; it would have been for everything that came after.

What customers need to establish

A customer considering Elba must define the actual intended use. “Customer-service AI” is not a sufficiently precise regulatory description. The assessment needs to identify what Elba receives, what it produces, which actions it can take, which systems it connects to, whether a human reviews its outputs and whether the workflow affects a consequential decision.

Where the deployment remains within an approved non-high-risk use category, the customer will ordinarily be a deployer of a non-high-risk interactive AI system. The customer must ensure that the deployment remains within its agreed purpose and configuration, maintain appropriate human involvement, provide any customer-side notices, ensure sufficient AI literacy and submit material changes for review. Where a use may alter the classification, we assess it before deployment. Where it is prohibited, we do not approve it.

Kolsetu provides the intended-purpose boundaries, classification position, impact-assessment approach, Article 50 controls, privacy and security documentation and contractual responsibilities needed to support that process. The objective is not to send procurement a folder called “EU AI Act” and hope the folder name carries the argument.

What we can say about Elba

We describe Elba as EU AI Act compliant, and we do so deliberately. For customers and website visitors, the wording needs to be clear rather than buried beneath a paragraph of legal qualifications. But the claim is backed by a defined intended purpose, documented classification, implemented transparency controls, AI governance framework and clear boundaries around uses that require separate review.

EU AI Act compliance is not a magic property attached permanently to every conceivable Elba configuration. Our claim applies to Elba within its documented intended purpose and approved use categories. A customer that materially changes the system, uses it for a prohibited purpose or deploys it in a potential high-risk context may change the legal position and trigger additional obligations.

What we can say with confidence is that Elba’s ordinary intended uses are assessed as outside the prohibited and Annex III high-risk categories; mandatory AI interaction disclosure is implemented as a platform control; the Article 50 marking programme is governed against the applicable deadline; and the supporting classification, impact assessment, AI literacy, risk-management and lifecycle controls are documented and operational.

In practical terms, we have:

• Completed and documented an EU AI Act classification and risk assessment for Elba.
• Maintain approved-use baselines and defined triggers for deployment-specific review.
• Maintain a formal Article 50 Compliance Position and have signed the provider section of the European Commission’s Code of Practice on Transparency of AI-Generated Content.
• Maintain an AI policy, development work instruction, AI Tool Register, DPIA, ISO/IEC 42001-aligned impact assessment, NIST AI Risk Management Framework maturity assessment, AI literacy programme and lifecycle risk process connected to our ISO 27001 management system.
• Implemented ISO/IEC 42001 as our internal AI management framework.
• Documented in detail what Elba is not intended to do, which uses require review and which uses we will not support.

That is not a promise that every conceivable deployment remains compliant regardless of how it is changed or used. It is evidence that the platform has a defined compliance position, its boundaries are documented and uses outside those boundaries should not reach production unnoticed.

And frankly, after the amount of work involved, this is the point at which one is entitled to stand quietly for a moment and admire the evidence register.

In summary

The EU AI Act is intended to make AI safer, more transparent and more accountable without regulating every system as though it were deciding who receives a mortgage, a job or a prison sentence.

Elba’s standard role is to communicate, gather information, orchestrate workflows, interact with approved systems and support human-led processes. We have defined that role, assessed it against the Act, considered its wider impacts and implemented controls designed to keep ordinary deployments within the approved boundaries.

Where a customer proposes something materially different, we reassess it. Where the use is prohibited, we do not support it. Where the deployment may be high-risk, we do not pretend that a general platform assessment settles the matter.

We are approaching the deadline with more than optimism, a spreadsheet and a meeting booked for next Thursday. The intended purpose is defined, the classification and impact assessment are complete, the disclosure control is live, and the remaining Article 50 work has a clear owner, evidence requirements and a statutory deadline.

For the briefest flutter of an eyelid, we have reached Ithaca. We will enjoy the view until the next EU AI Act release notes arrive.