Sightadel

Solutions · AI providers and deployers

The AI is already running.
Now someone asks who is in control.

If you develop, provide or deploy AI, three sets of rules apply: the EU AI Act, data protection and, when customers ask for proof, ISO/IEC 42001. Sightadel helps you clarify role and risk class per system, sorts the obligations by their deadlines and records what is evidenced.

Starting point

What it looks like in practice.

AI is now part of many processes, often without anyone having the full picture. Your own product uses a language model, customer service a chatbot, HR a tool that pre-sorts applications. Some systems were built by development, others arrived with an update to standard software. Who is responsible for which system, what data it works with and how it was tested is rarely recorded in one place.

The AI Act, Regulation (EU) 2024/1689, ties in exactly here. It distinguishes by role and risk. Providers develop an AI system or place it on the market under their own name and bear most of the obligations. Deployers use a system under their own responsibility. Many companies are both: provider for their own product, deployer for the tools in-house. The GDPR also applies as soon as personal data is involved, which is often the case in training as well as in operation.

At the same time, customers are asking questions. Purchasing and information security want to know where training data comes from, how results are monitored and who steps in when a system gets it wrong. An AI management system under ISO/IEC 42001 gives a structured answer. Whether you have it certified is a second decision. You need the structure behind it for the regulation anyway.

Why now

Typical reasons to tackle the topic.

01

AI Act deadlines

The prohibitions and the AI literacy obligation have applied since February 2025, the rules for general-purpose AI models since August 2025, the transparency obligations since August 2026. The high-risk obligations were postponed in 2026, to December 2027 for stand-alone systems and to August 2028 for AI in regulated products. Setting things up takes time, so it pays to start now.

02

A customer asks for proof

A business customer sends a questionnaire on AI governance or puts ISO/IEC 42001 into a tender. If you have evidenced your inventory, risk assessment and responsibilities, you can answer in days rather than weeks.

03

New product or new purpose

A new feature assesses people, decides on access to services or is built into a medical device or machinery product. That can change the risk class. The classification should be in place before market launch, not after.

04

Enquiry from the data protection authority

A data subject asks why their data ended up in training, or objects to an automated decision. Then what counts is the legal basis, impact assessment and privacy notices recorded beforehand.

05

Funding or sale

Investors and buyers now check whether an AI product is viable from a regulatory point of view. A traceable classification and well-maintained evidence shorten this review.

06

AI tools are spreading in-house

Employees use assistants for texts, code and analyses, some with their own accounts. Management wants to know what is allowed, who is trained and what data leaves the company.

Relevant frameworks

What applies – and what it specifically requires here.

Summarised in our own words, not legal advice. The original text in its current version is authoritative.

EU AI ActMandatory

Applies to providers and deployers of AI systems in the EU, regardless of company size. How much follows from it depends on role and risk class. AI literacy and checking for prohibited practices concern everyone. Transparency obligations apply, for example, to chatbots and artificially generated content. For high-risk systems, risk management, technical documentation, human oversight and, for providers, a conformity assessment are added. There is no certificate for the regulation as a whole.

View framework →
GDPRMandatory

As soon as training data, inputs or outputs relate to people, the GDPR applies. For training, you need a sound legal basis and clear information for data subjects. New high-risk processing requires a data protection impact assessment. Where a system alone decides about people, Art. 22 sets tight limits and requires ways for data subjects to intervene.

View framework →
ISO/IEC 42001Often required

The standard describes a management system for AI and is structured like ISO/IEC 27001. It is voluntary but increasingly requested by business customers. Inventory, responsibilities, risk assessment and impact assessment form the organisational foundation for many obligations of the regulation. It does not replace conformity assessment and registration.

View framework →
ISO/IEC 27001Recommended

If you offer AI as a service, you will be asked about information security, often before the AI itself. An ISMS provides access control, logging, vendor assessment and incident handling. This evidence also carries over to the requirements for robustness and cybersecurity.

View framework →

Recommended order

Where to start – and what comes next.

  1. 1

    Create an AI inventory

    Record every system with its purpose, owner, data sources and provider. This includes embedded features in standard software and cloud services. Without a complete list, nothing can be classified.

  2. 2

    Determine role and risk class

    For each system, you clarify whether you are provider or deployer, rule out prohibited practices and record the risk class with a justification. You have borderline cases reviewed legally. The decision remains yours.

  3. 3

    Obligations already in force first

    AI literacy for employees, transparency notices and an AI policy from management already apply. They can be implemented and evidenced in a few weeks. In parallel, you review the processing activities in the record of processing activities and the required impact assessments.

  4. 4

    Build the management system

    Risk assessment, impact assessment, life cycle and data quality are defined as repeatable procedures. You work through the controls in Annex A of ISO/IEC 42001 step by step and justify their applicability. An existing ISMS is put to use as well.

  5. 5

    Prepare high-risk systems

    Only if affected: prepare technical documentation, logging, human oversight and data governance. Providers plan the conformity assessment so that it is completed before the postponed deadlines.

  6. 6

    Maintain and present again

    New models, new data sources and new purposes change the classification. Inventory and assessments are reviewed with every change and at fixed intervals. Training is repeated.

Data protection for AI

The questions where AI projects get stuck on data protection

The AI Act does not replace the GDPR. Both apply side by side. Four points should be clarified and recorded before deployment.

Legal basis for training data

Data collected for another purpose may not simply flow into training. Whether legitimate interest, consent or contract applies depends on the individual case. Record the balancing and the result per data source. For health data or other special categories of data, the hurdles are considerably higher.

Data protection impact assessment

New technologies likely to pose a high risk to data subjects require an impact assessment before launch. For AI systems that assess people or analyse large volumes of data, this is the rule. The impact assessment under ISO/IEC 42001 and the fundamental rights impact assessment under the regulation interlock.

Automated decisions

If a system decides about a person without human review, with legal or similarly significant effect, Art. 22 GDPR applies. Then you need an exception, safeguards and the right to involve a human. An approval that merely rubber-stamps does not count as human review.

Transparency towards data subjects

Data subjects learn that their data flows into an AI system, for what purpose and with what logic, where this is required. Privacy notices and the transparency notices under the AI Act should match and not be written separately by two departments.

Effort and duration

An honest estimate.

Company that only deploys AI6–10 weeks
Inventory, classification, training, AI policy and transparency notices. As long as no use falls into a high-risk area, it stays with these basic obligations and data protection.
Provider without a high-risk system2–4 months
In addition, transparency in the product, data protection for training data, vendor assessment and an answer to customer questionnaires. ISO/IEC 42001 certification usually takes four to eight months.
Provider of a high-risk system9–15 months
Risk management, technical documentation, data governance, quality management and conformity assessment. The duration depends heavily on how much of this is already recorded during development.

The ranges are based on experience, not a commitment. If you already run an ISMS under ISO/IEC 27001, you will make much faster progress, because management, the risk process and internal audit are already in place.

What you license · typically Professional

An AI provider typically starts with data protection, ISO/IEC 42001 and the AI Act in the Professional edition. It includes ten users, ten assets and 25 vendors, which is enough for development, product, data protection and management. We offer ISO/IEC 42001 and the AI Act on request. Companies that only deploy AI often start with data protection and the regulation.

Licence per framework, minimum term one year, payable monthly or annually. You will find all prices, discounts and a calculator on the pricing page. Fees of a certification or audit body are charged separately.

Questions and answers

Questions about AI providers and deployers

More in our FAQ or directly via our contact form.

Are we a provider or a deployer?

That depends on the individual system. If you develop an AI system or place it on the market under your own name, you are a provider. If you use someone else's system under your own responsibility, you are a deployer. Many companies are both. In Sightadel, you record the role per system. The final classification is a legal question for your advisers.

Our product is built on a third-party language model. What applies to us?

For the model itself, its provider bears the obligations for general-purpose models. For your system that uses the model, you are usually the provider yourself. You then need documentation from the model provider to meet your own obligations. Manage them in Sightadel as a vendor with an assessment.

Which deadlines apply now?

Prohibitions and AI literacy since February 2025, rules for general-purpose AI models since August 2025, transparency obligations since August 2026. The high-risk obligations were postponed in 2026: to December 2027 for stand-alone systems, to August 2028 for AI in regulated products.

Do we need ISO/IEC 42001 to comply with the regulation?

No. The standard is voluntary. But it provides the organisational foundation the regulation presupposes: inventory, responsibilities, risk assessment, impact assessment. You check statutory steps such as conformity assessment, registration and certain transparency obligations separately.

May we use customer data for training?

Not without review. You need a legal basis for exactly this purpose, information for data subjects and often a data protection impact assessment. Contractual commitments to customers may also rule it out. Sightadel guides you through the questions and records the result; the legal assessment lies with your data protection officer or your advisers.

Who audits us, and does Sightadel certify?

Sightadel does not certify. ISO/IEC 42001 certification is issued by an accredited body. For high-risk systems, the conformity assessment is carried out internally or by a notified body, depending on the system. You choose auditors from our independent partner network or yourself. No commission is paid for audits, neither to us nor to the partners.

Does the AI in Sightadel fill in the classification for us?

No, on purpose. It provides drafts from templates and offers drafting help. You decide on role, risk class and residual risks yourself, because you must be able to defend these decisions to authorities and customers. For difficult cases, you can book consulting as a package in the app.

Where are our documents stored?

Sightadel is developed in Germany and operated in Germany. We conclude a data processing agreement (DPA) under Art. 28 GDPR with every customer. Training data and models do not belong in Sightadel, only the documentation about them.

Content reviewed by experts on 8 October 2026 · Not legal advice. The standard or law in its current version is authoritative.

Start with one standard.

14 days, full access, no payment details. Everything you set up carries over into the paid plan.