DEV Community: AnnexOps

Managing Third-Party AI Risks in Software Development: A Practical Guide to the EU AI Act

AnnexOps — Thu, 05 Nov 2026 06:32:18 +0000

Modern software rarely operates in isolation. Applications depend on external APIs, cloud services, open-source libraries and third-party models. With generative AI becoming part of everyday development, these dependencies now include large language models, AI-powered SaaS tools and machine learning services.

Integrating an external AI model can take only a few lines of code. Understanding its risks and regulatory implications is considerably more complicated.

For example, imagine a SaaS company adding an external LLM API to its customer support application. The engineering team handles the integration, the vendor operates the model, and the product team controls how customers interact with it.

Who is responsible for the resulting AI system? What happens when the vendor changes its model? Can the company access enough technical information to document its system?

These questions are central to AI vendor risk management.

The EU AI Act makes it important for organisations to understand their responsibilities across the AI value chain. Using an external model does not automatically transfer every regulatory responsibility to its supplier.

For developers and engineering teams, this means third-party AI dependencies need to become part of the software governance process.

1. Why Third-Party AI Dependencies Need More Attention

Traditional software supply-chain management focuses on dependencies such as libraries, packages, infrastructure and external services.

AI introduces additional considerations.

A third-party AI service can influence:

How application data is processed.
What outputs are generated.
How users interact with a product.
Whether decisions are influenced by automated predictions.
Which technical documentation is available.
How system behaviour changes after model updates.

Consider an application that uses an external AI model to screen job applications. The application developer may not have trained the underlying model, but the way the model is integrated and used can have significant regulatory implications.

A supplier's security certification alone does not answer questions about intended purpose, AI risk classification, human oversight or technical documentation.

This is why third-party AI risk management should be integrated into software architecture, procurement and release processes.

Provider vs. Deployer: Understand Your Role Before Integration

Using an external AI chatbot internally: The organisation may act as a deployer. Applicable deployer responsibilities should be assessed.
Integrating an external model into a commercial SaaS product: The organisation may become the provider of the resulting AI system. Its intended purpose, product design and provider obligations should be examined.
Rebranding an existing high-risk AI system: The organisation may become the provider where the conditions under Article 25 apply.
Substantially modifying a high-risk AI system: The modification may trigger provider responsibilities, depending on the applicable legal conditions.

The exact role depends on the facts and applicable legal conditions. Simply connecting to an external API does not automatically determine the organisation's role.

For engineering teams, this assessment should be documented alongside the AI system's architecture and intended purpose.

A useful starting point is an EU AI Act compliance framework that helps teams understand the relationship between system classification, provider and deployer roles, and regulatory obligations.

What the EU AI Act Means for AI Vendors and Software Teams

Several provisions are particularly relevant when building software around third-party AI services.

Article 25(4): Technical Cooperation With Third Parties

Article 25(4) addresses relationships between providers of high-risk AI systems and third parties supplying AI systems, tools, services, components or processes used in or integrated into those systems.

Where applicable, the parties must establish a written agreement specifying the information, capabilities, technical access and assistance required for the provider to meet its obligations.

For developers, this can affect vendor selection and integration architecture.

Before adopting an external AI component, teams should consider:

Can the supplier provide the required technical information?
Are relevant system limitations documented?
Can the supplier communicate significant changes?
Are responsibilities for technical cooperation included in the agreement?

These questions should be considered before an integration becomes difficult to replace.

Article 53: General-Purpose AI Model Documentation

Article 53(1)(b) requires providers of general-purpose AI models to prepare and maintain technical documentation and make relevant information available to downstream providers intending to integrate the model into their AI systems.

Annex XII specifies the information required.

This is important for developers using external foundation models. Documentation can help teams understand model capabilities, limitations and integration requirements.

When evaluating a model provider, technical documentation should be part of the selection process rather than something requested only when an audit approaches.

Article 26: Responsibilities of Deployers

Organisations deploying high-risk AI systems have responsibilities under Article 26.

Depending on the applicable requirements, these include using systems according to their instructions, assigning competent human oversight, monitoring operation and retaining automatically generated logs under their control for the required period.

For software teams, these responsibilities can influence application design.

For example, a high-risk AI application may need clear escalation paths, appropriate human review and reliable logging mechanisms. These should be considered during development rather than added as an afterthought.

Build an AI Inventory That Includes External Services

A useful AI system inventory should capture more than a product name. For each system, record:

AI system name: Identifies the application or model.
Vendor or provider: Establishes the external dependency.
Intended purpose: Explains how the system is used.
Internal owner: Identifies accountability.
Data processed: Supports privacy and security reviews.
Provider/deployer role: Helps determine regulatory responsibilities.
Risk classification: Records the assessment.
Technical documentation: Supports traceability.
Last assessment date: Helps manage reassessment.

This inventory should be updated when new models are integrated, APIs are replaced or the system's intended purpose changes.

5. A Practical AI Vendor Assessment Workflow

A vendor questionnaire is useful, but it should be part of a wider process.

A practical workflow can be divided into six steps.

Step 1: Identify the AI Dependency

Start by identifying the external model, API or AI-enabled service.

Document its intended purpose, business use case, technical owner and integration points.

Step 2: Determine the Regulatory Role

Assess whether the organisation acts as a provider, deployer or both in relation to the system.

Do not assume that the original model supplier retains every responsibility after integration.

Step 3: Review Technical Documentation

Request relevant information about:

Model capabilities and limitations.
Intended purpose and instructions for use.
Technical architecture.
Known performance limitations.
Relevant model updates.
Available logs and monitoring information.

The exact documentation required depends on the system and applicable legal obligations.

Step 4: Assess Security and Privacy

Review how the vendor processes application data.

Important questions include:

Is customer data used for model training?
Where is data stored and processed?
What encryption and access controls are implemented?
How are incidents communicated?
Which subprocessors are involved?
Can the supplier support relevant GDPR obligations?

Step 5: Review Contracts and Responsibilities

Contractual arrangements should address responsibilities, documentation access, change notifications, incident handling and technical cooperation.
For high-risk AI systems, consider the specific requirements of Article 25(4) where applicable.

Step 6: Monitor the Integration

Vendor approval should not be treated as permanent.

Reassess the dependency when the model changes, a new subprocessor is introduced, the intended purpose changes or a security incident occurs.

This creates a repeatable AI vendor due diligence process instead of a one-time procurement exercise.

Bring AI Vendor Governance Into the Software Development Lifecycle

Teams can introduce governance checkpoints at different stages of development:

Planning: Identify AI use cases and external dependencies.
Vendor selection: Review technical, security and regulatory information.
Architecture design: Document data flows, model dependencies and intended purpose.
Development: Maintain integration records and relevant technical documentation.
Testing: Evaluate limitations, performance and potential risks.
Release: Review approvals and applicable obligations.
Production: Monitor incidents, model changes and system behaviour.

This approach connects AI governance with existing engineering workflows without making every minor model update a full legal review.

Teams can also use version control to track configuration changes, maintain records of model versions and document why a particular vendor or model was selected.

7. How ISO 42001 and ISO 27001 Fit Into AI Supplier Management

Two management-system standards can help organisations structure supplier governance.

ISO/IEC 42001:2023 includes controls for third-party and customer relationships in Annex A.10:

A.10.2 – Allocation of responsibilities.
A.10.3 – Suppliers.
A.10.4 – Customers.

These controls help organisations define responsibilities and manage relationships involving AI systems.

ISO/IEC 27001:2022 includes supplier security controls 5.19 to 5.23. They address supplier relationships, agreements, ICT supply chains, supplier service monitoring and cloud services.

For software teams, these frameworks can provide a foundation for connecting AI governance with existing information security and supplier management processes.

However, ISO certification does not automatically demonstrate that a particular AI system complies with every applicable EU AI Act requirement.

The ISO 42001 AI management system provides a useful reference for understanding how AI governance controls can be organised across an organisation.

What Should You Monitor After an AI Vendor Is Approved?

AI systems are not static software dependencies.

An external provider may update a model, change API behaviour, introduce new subprocessors or modify data processing arrangements.

A practical monitoring process should consider:

Model changes: Has the vendor changed the model version, capabilities or limitations?
API changes: Have endpoints, permissions, rate limits or integration requirements changed?
Data processing: Has the vendor changed its data retention, storage or training policies?
Security incidents: Has the supplier reported a breach or service disruption?
Intended purpose: Is the organisation using the system differently from its original assessment?
Documentation: Are the technical records and supplier agreements still current?

Not every change creates a new legal obligation. However, significant changes should trigger a review to determine whether the existing assessment remains appropriate.

9. Avoid These Common Third-Party AI Risk Mistakes

A few mistakes repeatedly create problems for organisations adopting external AI services.

Assuming the vendor owns all compliance responsibilities. The organisation must assess its own role and obligations.

Integrating first and documenting later. Important technical and contractual information may be difficult to obtain after implementation.

Ignoring AI services used by individual teams. Shadow AI can create untracked dependencies and data protection risks.

Treating certificates as complete evidence. A vendor's ISO certificate does not replace an assessment of the actual AI service and its intended use.

Failing to monitor model updates. A system's risk profile may change as its functionality, data flows, or deployment context evolves.

A clear inventory, documented assessment, and ongoing monitoring process can help prevent these gaps.

Conclusion: Treat AI Vendors as Part of Your Software Supply Chain

Third-party AI services are becoming standard components of modern software products. They speed development and provide access to advanced capabilities, but they also introduce dependencies that must be understood and managed.

The EU AI Act makes it important to identify your role, assess relevant risks, obtain appropriate documentation, and maintain oversight of AI systems throughout their lifecycle.

For engineering teams, the practical starting point is straightforward:
Identify every AI dependency.

Document its intended purpose and supplier.
Assess provider and deployer responsibilities.
Review technical, security, and privacy information.
Connect governance checks with development workflows.
Monitor significant vendor and model changes.

AI vendor risk management should not become a separate paperwork exercise. It should be part of how teams design, build, deploy, and maintain AI-powered software.

From ISO 27001 to ISO 42001: A Practical AI Governance Implementation Guide

AnnexOps — Thu, 29 Oct 2026 05:59:56 +0000

AI systems introduce governance challenges that traditional information security processes may not fully address. A company can have an established Information Security Management System (ISMS), documented security controls, and an internal audit programme while still lacking processes for AI system impact assessments, model governance, and AI-specific risk management.

This is where ISO/IEC 42001:2023 becomes relevant.

ISO 27001 focuses on information security management, whereas ISO 42001 specifies requirements for establishing and continually improving an Artificial Intelligence Management System (AIMS). For engineering teams that already work with ISO 27001, the transition can involve reusing suitable management processes and extending them to cover AI-specific requirements.

The important part is understanding what can be reused, what needs to be added, and how to maintain evidence as AI systems evolve.

Why Does ISO 27001 Alone Not Cover Every AI Governance Requirement?

Information security remains an essential part of AI governance, but it is not the only concern.

Consider an application that uses a third-party language model to process customer requests. The engineering team may already assess access controls, encryption, data confidentiality, and supplier security under its ISMS.

However, additional questions may arise:

Can the model produce biased or inappropriate outputs?
Are the training or input data suitable for the intended purpose?
When should a human review an AI-generated decision?
How are changes to the model evaluated before deployment?
What documentation is needed to explain the system's behaviour and limitations?
How are AI-related risks monitored after release?

These questions require processes that address AI systems and their lifecycle, rather than information security alone.

ISO 42001 provides a management-system framework for organising this work.

What Can Engineering Teams Reuse From ISO 27001?

ISO 27001 and ISO 42001 share the same general harmonized management-system structure across clauses 4 to 10. This creates opportunities to coordinate activities instead of maintaining two completely separate management systems.

1. Risk management workflows

An existing risk register can provide a useful starting point for AI governance.

For example, an engineering team may already document security risks, assign owners, define mitigation measures, and review outstanding issues. These practices can support the AIMS, provided the risk methodology is extended to address relevant AI-related risks and opportunities.

AI-specific assessments may need to consider bias, explainability, data quality, human oversight, and potential impacts on people.

2. Document control and evidence

Many organisations already use version-controlled repositories, ticketing systems, approval workflows, and audit records.

These systems may help maintain AI policies, risk assessments, technical documentation, review decisions, and corrective actions.

The objective is not to create a separate document for every standard. It is to maintain reliable records that can be traced to the requirements they support.

3. Internal audits and management reviews

Existing audit schedules and management review processes may also be coordinated.

However, audit criteria must cover the requirements of both standards. An ISMS audit that focuses only on information security does not automatically establish that an AIMS is effective.

For more detail on shared processes and standard-specific requirements, see the ISO 27001 and ISO 42001 integration guide.

A Practical ISO 42001 Implementation Workflow

A phased approach can help technical teams identify gaps and introduce AI governance without unnecessarily duplicating existing work.

Step 1: Inventory your AI systems

Start by identifying the AI systems used, developed, provided, or deployed within the proposed AIMS scope.

Depending on your organisation, the inventory may include:

Internally developed machine learning models
Third-party language models and APIs
AI-enabled SaaS products
Retrieval-augmented generation applications
Automated decision-support systems
AI components integrated into production services

For each system, record its intended purpose, owner, deployment environment, relevant data sources, external dependencies, and lifecycle status.

This inventory creates a shared reference point for risk assessments, governance decisions, and change management.

Step 2: Define the AIMS scope and responsibilities

Determine which organisational activities and AI systems fall within the management system.

Assign responsibilities across engineering, security, product management, legal, and compliance teams as appropriate.

For example, an ML engineer might maintain model documentation, a security engineer might assess technical vulnerabilities, and a product owner might coordinate reviews of intended use and operational changes.

These are possible organisational arrangements, not job titles mandated by ISO 42001.

Step 3: Perform an AI-specific gap analysis

Compare your current management processes with the requirements of ISO 42001.

Review areas such as:

AI policy and governance responsibilities
AI risk assessment and treatment
AI system impact assessment
AI objectives and performance evaluation
Data and AI lifecycle management
Human oversight and relevant transparency processes
Third-party AI relationships
Internal audit and continual improvement

Record each gap, the required action, its owner, and the evidence needed to demonstrate implementation.

An existing ISO 27001 certification does not automatically satisfy ISO 42001 requirements.

Teams planning this transition can use the ISO 42001 implementation guide for ISO 27001 holders as a reference for organising implementation phases and identifying areas that require additional work.

Step 4: Assess AI risks and impacts

Risk assessment should reflect the context and intended use of each AI system.

For a customer-facing chatbot, the assessment might examine inaccurate responses, inappropriate disclosures, data handling, and the need for human escalation.

For an AI recruitment system, relevant considerations might include potentially discriminatory outcomes, data representativeness, explainability, and human review.

The assessment process should produce documented findings and decisions. These results can inform risk treatment, AI objectives, and the selection of applicable controls.

ISO 42001 addresses AI system impact assessment as well as AI-related risk management. The two activities should not be treated as interchangeable.

Step 5: Map and implement the controls

Annex A of ISO 42001 contains 38 reference controls organised into nine control objectives.

These objectives cover AI policies, internal organisation, resources, AI system impact assessment, the AI system lifecycle, data, information for interested parties, AI system use, and third-party and customer relationships.

Build a control map that identifies the applicable requirements, current processes, gaps, owners, and supporting evidence.

Where an existing security process supports an AI governance objective, document the relationship. Where it does not cover the relevant requirement, introduce an additional control or process.

The mapping should be based on the actual requirements and the organisation's circumstances, rather than assumptions that similarly named controls are equivalent.

Step 6: Integrate governance into the software development lifecycle

For engineering teams, AI governance is easier to maintain when it connects to existing development workflows.

Consider introducing the following practices:

Before deployment: Review intended use, relevant risks, data considerations, and required approvals.

During development: Maintain model and system documentation, track relevant changes, and record assessment results.

Before significant changes: Evaluate whether a model update, new data source, or change in intended purpose requires another risk or impact assessment.

After deployment: Monitor relevant performance indicators, record incidents, and assign corrective actions where necessary.

The exact controls depend on the system, its context, and applicable requirements. ISO 42001 does not prescribe a single CI/CD implementation for every AI application.

Step 7: Audit and improve the management system

Conduct an internal audit against the applicable ISO 42001 requirements and defined audit criteria.

Review the implementation of controls, the quality of evidence, assigned responsibilities, and the operation of risk and impact assessment processes.

Management review should evaluate the suitability, adequacy, and effectiveness of the AIMS. Track findings and corrective actions rather than treating the audit as the final step.

Organisations seeking certification should coordinate with an appropriate certification body.

How Can Teams Manage AI Governance Evidence?

A common operational problem is that evidence becomes scattered across Git repositories, spreadsheets, project management tools, shared drives, and approval systems.

This can make it difficult to determine which AI systems have been assessed, who approved a decision, and whether the supporting documentation is current.

A central evidence structure can help.

For example, an organisation might maintain the following relationships:

AI system inventory → identifies the system and its owner.
Risk assessment → records identified risks and treatment decisions.
Control mapping → connects requirements to implemented processes.
Technical documentation → describes relevant system characteristics and limitations.
Approval records → establish who reviewed and authorised a decision.
Monitoring records → provide evidence of ongoing review and improvement.

These relationships can be maintained in existing tools or supported by dedicated AI governance software.

The objective is traceability: teams should be able to move from an AI system to its relevant assessments, controls, decisions, and evidence without reconstructing the history manually.

Where Does the EU AI Act Fit Into ISO 42001?

ISO 42001 is a voluntary management-system standard, while the EU AI Act establishes legal obligations for relevant AI systems and actors.

An AIMS can support governance processes, documentation, and risk management. However, ISO 42001 certification alone does not establish compliance with the EU AI Act.

Organisations must separately determine their applicable legal obligations, including relevant requirements for high-risk AI systems, transparency, AI literacy, and other provisions where applicable.

The legal roles of provider and deployer also need to be assessed under the EU AI Act. They should not be inferred solely from an organisation's internal governance responsibilities.

For teams coordinating management-system work with regulatory requirements, an integrated approach can reduce duplicated effort while preserving the distinction between voluntary standards and legal obligations.

Can AI Compliance Software Support the Implementation?

AI governance software can help organisations connect AI inventories, risk assessments, control mappings, and evidence records in one workflow.

AnnexOps is one option for teams managing ISO 42001, ISO 27001, and EU AI Act compliance operations. Its ISO 27001 compliance solution describes support for ISMS scope, risk registers, controls, evidence, and internal audits.

Software selection should depend on the organisation's scope, existing tools, evidence requirements, and workflow needs. A platform can support compliance operations, but it does not replace management accountability, legal assessment, or an independent certification audit.

Final Thoughts

Moving from ISO 27001 to ISO 42001 is an extension of management-system capabilities, not simply a change in security documentation.

Engineering and compliance teams can make the transition more manageable by inventorying AI systems, defining responsibilities, assessing AI-specific risks and impacts, mapping controls, and maintaining traceable evidence.

The most sustainable approach is to connect governance activities to the software lifecycle and existing management processes while preserving the requirements unique to each standard.

For a detailed phase-by-phase roadmap, read the ISO 42001 implementation guide for organisations that already have ISO 27001.

DSGVO-Compliance in der Softwareentwicklung: 6 technische Prüfungen für Entwicklerteams

AnnexOps — Wed, 28 Oct 2026 09:10:03 +0000

Ein praxisorientierter Leitfaden zu Datenschutz, Datenflüssen und Compliance-Nachweisen im Entwicklungsprozess.

Datenschutz wird in vielen Softwareprojekten erst dann ausführlich behandelt, wenn ein Produkt kurz vor der Veröffentlichung steht oder eine Datenschutzprüfung ansteht. Zu diesem Zeitpunkt können grundlegende Entscheidungen bereits feststehen: Welche Daten werden gespeichert? Welche externen APIs erhalten Zugriff? Wie lange bleiben Protokolle erhalten? Und wer kann personenbezogene Informationen einsehen?

Für Entwicklerteams ist es deshalb sinnvoll, Datenschutzanforderungen frühzeitig in den Software Development Lifecycle (SDLC) einzubeziehen.
Die Datenschutz-Grundverordnung (DSGVO) betrifft nicht nur juristische Dokumente. Sie kann auch Architekturentscheidungen, Datenbankmodelle, Berechtigungskonzepte, Logging, Monitoring und den Betrieb von Anwendungen beeinflussen.

Die folgenden sechs Prüfungen helfen Ihnen, Datenschutzanforderungen in konkrete technische Aufgaben zu übersetzen.

1. Erfassen Sie personenbezogene Daten und ihre Datenflüsse

Bevor Sie Datenschutzmaßnahmen implementieren, sollten Sie nachvollziehen können, welche personenbezogenen Daten Ihr System verarbeitet.
Dazu gehören nicht nur offensichtliche Informationen wie Namen und E-Mail-Adressen. Je nach Kontext können auch IP-Adressen, Gerätekennungen, Nutzungsdaten oder Kennungen in Anwendungsprotokollen personenbezogen sein.

Erstellen Sie eine Übersicht mit folgenden Informationen:

Welche Daten werden erfasst?
Aus welcher Quelle stammen sie?
Zu welchem Zweck werden sie verarbeitet?
In welchen Datenbanken oder Diensten werden sie gespeichert?
An welche externen Systeme werden sie übermittelt?
Wie lange werden sie aufbewahrt?

Ein vereinfachtes Beispiel für eine Webanwendung könnte so aussehen:

Praktischer Tipp: Dokumentieren Sie Datenflüsse gemeinsam mit Ihrer Systemarchitektur. Aktualisieren Sie die Dokumentation, wenn Sie neue Dienste integrieren oder bestehende Verarbeitungsvorgänge verändern.

2. Implementieren Sie Datenschutz durch Technikgestaltung

Art. 25 DSGVO behandelt Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. Für Entwicklerteams bedeutet das unter anderem, Datenschutz bereits bei Architektur und Implementierung zu berücksichtigen.

Ein häufiger Ansatz ist die Datensparsamkeit: Erheben und verarbeiten Sie nur die personenbezogenen Daten, die für den jeweiligen Zweck erforderlich sind.

Prüfen Sie beispielsweise:

Werden unnötige Profilfelder erfasst?
Sind sensible Informationen in API-Antworten enthalten, obwohl sie nicht benötigt werden?
Haben Benutzer standardmäßig Zugriff auf zu viele Daten?
Werden personenbezogene Daten länger gespeichert als erforderlich?
Sind datenschutzfreundliche Einstellungen standardmäßig aktiviert?

Ein API-Endpunkt sollte beispielsweise nicht automatisch sämtliche Daten eines Benutzerkontos zurückgeben, wenn die jeweilige Funktion nur den Anzeigenamen benötigt.

Auch die Trennung von Test- und Produktionsdaten ist wichtig. Verwenden Sie für Entwicklung und Tests möglichst synthetische oder angemessen anonymisierte Daten, statt produktive personenbezogene Datensätze unkontrolliert zu kopieren.

3. Überprüfen Sie Berechtigungen und Datenzugriffe

Ein funktionierendes Authentifizierungssystem allein gewährleistet noch keine angemessene Zugriffskontrolle.

Ihre Anwendung sollte prüfen, ob ein Benutzer tatsächlich berechtigt ist, auf die angeforderten Daten zuzugreifen. Diese Prüfung muss serverseitig erfolgen und darf nicht ausschließlich von der Benutzeroberfläche abhängen.

Eine technische Überprüfung kann folgende Fragen umfassen:

Werden Berechtigungen bei jedem relevanten API-Aufruf geprüft?
Sind Rollen und Zugriffsrechte klar definiert?
Können Benutzer fremde Datensätze durch manipulierte IDs abrufen?
Sind administrative Funktionen ausreichend geschützt?
Werden Zugriffe auf sensible Informationen angemessen protokolliert?

Ergänzen Sie Ihre automatisierten Tests um Fälle, in denen ein Benutzer versucht, auf Daten eines anderen Kontos zuzugreifen.

Beispielsweise sollte ein Test nicht nur bestätigen, dass ein berechtigter Benutzer seine Daten abrufen kann. Er sollte auch prüfen, dass ein nicht berechtigter Benutzer keinen Zugriff erhält.

Solche Tests unterstützen die technische Umsetzung geeigneter
Sicherheitsmaßnahmen. Die konkrete Ausgestaltung muss sich an den Risiken und Anforderungen des jeweiligen Systems orientieren.

4. Gestalten Sie Logging und Monitoring datenschutzbewusst

Logs sind für Fehleranalyse, Sicherheitsüberwachung und Incident Response wichtig. Gleichzeitig können sie personenbezogene Informationen enthalten.
Ein häufiger Fehler besteht darin, vollständige API-Anfragen oder Antworten zu protokollieren. Dadurch können beispielsweise E-Mail-Adressen, Zugriffstoken oder andere vertrauliche Angaben in Logsysteme gelangen.

Prüfen Sie deshalb Ihre Logging-Konfiguration:

Vermeiden Sie unnötige personenbezogene Informationen.
Entfernen oder maskieren Sie sensible Felder, bevor Daten protokolliert werden.
Speichern Sie keine Passwörter oder geheimen Zugriffstoken in Logs.
Begrenzen Sie Zugriffsrechte auf zentrale Logsysteme.
Definieren Sie Aufbewahrungs- und Löschfristen.
Prüfen Sie, welche Daten externe Monitoring-Dienste erhalten.

Ein einfaches Beispiel für eine Lognachricht ohne unnötige Nutzerdaten:

logger.info("User profile updated", {
event: "profile_update",
requestId: request.id,
status: "success"
});

Die konkrete Implementierung hängt von Ihrem Logging-Framework ab. Entscheidend ist, dass Diagnoseinformationen verfügbar bleiben, ohne unnötig personenbezogene Daten zu sammeln.

5. Integrieren Sie Datenschutzprüfungen in CI/CD

Datenschutzanforderungen lassen sich nicht vollständig automatisieren. Bestimmte technische Kontrollen können jedoch in bestehende Entwicklungsprozesse integriert werden.

Eine CI/CD-Pipeline kann beispielsweise Tests und Prüfungen ausführen, bevor Änderungen bereitgestellt werden.

Ein einfaches Pipeline-Konzept könnte so aussehen:

Nicht jede Datenschutzanforderung lässt sich durch einen automatisierten Test abbilden. Ob beispielsweise eine Datenschutz-Folgenabschätzung erforderlich ist, hängt von der konkreten Verarbeitung und ihrer Risikosituation ab.

Die Pipeline sollte daher technische Kontrollen mit dokumentierten Prüf- und Freigabeprozessen verbinden.

6. Dokumentieren Sie Änderungen und Compliance-Nachweise

Software verändert sich kontinuierlich. Neue Funktionen, zusätzliche Datenfelder, externe Integrationen oder geänderte Speicherfristen können Auswirkungen auf bestehende Datenschutzprozesse haben.

Deshalb sollten Sie technische Änderungen mit den relevanten Dokumentationsaufgaben verbinden.

Eine praktische Checkliste für Code Reviews kann beispielsweise folgende Fragen enthalten:

Verarbeitet die Änderung neue personenbezogene Daten?
Ändert sich der Zweck einer bestehenden Verarbeitung?
Werden zusätzliche externe Dienste eingebunden?
Ändern sich Berechtigungen oder Speicherfristen?
Muss die Dokumentation der Verarbeitungstätigkeiten aktualisiert werden?
Ist eine zusätzliche Datenschutzprüfung erforderlich?

Nicht jede Codeänderung erfordert eine vollständige Datenschutzprüfung. Ein klar definierter Prozess hilft jedoch, relevante Änderungen frühzeitig zu erkennen.

Für Unternehmen mit umfangreichen Datenschutzprozessen kann eine zentrale Compliance-Lösung dabei helfen, Verantwortlichkeiten, Dokumente, Prüfungen und offene Maßnahmen zu verwalten. Die Software sollte dabei zu den tatsächlichen Arbeitsabläufen des Unternehmens passen.

Wie hängen technische Datenschutzmaßnahmen und Compliance-Software zusammen?
Technische Kontrollen und Compliance-Management erfüllen unterschiedliche Aufgaben.

Entwicklerteams implementieren beispielsweise Zugriffskontrollen, Datenminimierung, sichere Protokollierung und automatisierte Tests. Datenschutz- und Compliance-Verantwortliche beurteilen unter anderem die relevanten Verarbeitungsvorgänge, koordinieren erforderliche Bewertungen und organisieren Nachweise.

Eine gute Zusammenarbeit zwischen diesen Bereichen verhindert, dass technische Maßnahmen und Datenschutzdokumentation unabhängig voneinander gepflegt werden.

Wenn Sie unterschiedliche Lösungen für diese Aufgaben bewerten, können Sie sich anhand eines Vergleichs von fünf DSGVO-Compliance-Softwarelösungen für 2026 einen Überblick über mögliche Ansätze verschaffen.

Entscheidend ist nicht die Anzahl der Funktionen einer Plattform, sondern ob sie Ihre tatsächlichen Prozesse unterstützt und sich sinnvoll in bestehende Arbeitsabläufe integrieren lässt.

Fazit

Datenschutz sollte kein abschließender Kontrollschritt vor dem Produktstart sein. Er lässt sich besser in die Softwareentwicklung integrieren, wenn Datenflüsse dokumentiert, Berechtigungen getestet, Logs datenschutzbewusst gestaltet und relevante Änderungen nachvollziehbar verwaltet werden.

Die sechs Prüfungen bieten einen Ausgangspunkt für Entwicklerteams, die Datenschutzanforderungen systematischer in ihren Entwicklungsprozess einbeziehen möchten.

Beginnen Sie mit einer Übersicht der personenbezogenen Daten und ihrer Datenflüsse. Ergänzen Sie anschließend konkrete Tests und Prüfungen dort, wo sie in Ihre bestehende Architektur und CI/CD-Pipeline passen.

Integrating ISO 27001 and ISO 42001 Into an AI Development Workflow

AnnexOps — Fri, 23 Oct 2026 08:04:34 +0000

AI governance becomes more challenging when security and compliance activities sit outside the engineering process.

A development team might follow established security procedures, review access permissions, and document infrastructure changes. At the same time, its AI systems may introduce additional questions about intended use, model behaviour, risk ownership, and ongoing oversight.

Managing these responsibilities separately can create gaps between technical implementation and organizational governance.

ISO/IEC 27001 and ISO/IEC 42001 provide management-system frameworks that can help organizations address these challenges. The practical task is to connect governance requirements with the way software teams actually build, deploy, and maintain AI systems.

Why AI Teams Need More Than Security Controls

Information security is an important part of AI governance, but it does not cover every consideration associated with an AI system.

Consider an application that uses a third-party language model to summarize customer support conversations.

The engineering team might already have processes for protecting API credentials, controlling database access, and responding to security incidents. These practices help protect the application and its data.

However, the team may also need to consider whether model inputs expose sensitive information, whether outputs require human review, how changes to the model are evaluated, and who monitors the system after deployment.

These are different questions that require coordinated technical and organizational decisions.

ISO 27001 establishes a framework for information security management. ISO 42001 establishes a framework for managing AI-related risks and opportunities. Organizations can coordinate relevant processes while retaining the distinct requirements of each standard.

## Where the Two Standards Fit Into the Development Lifecycle

A useful approach is to connect management-system activities with existing engineering workflows rather than creating a separate process for every compliance task.

1. AI system planning

Before development begins, teams should understand the intended purpose of an AI feature and the responsibilities associated with it.

Useful questions include:

What business problem will the system address?
Will the system process personal, confidential, or otherwise sensitive information?
Which external models, APIs, or datasets will it depend on?
Who owns the system and approves important changes?
What risks need to be assessed before deployment?

Information security requirements can help establish safeguards for data and infrastructure. AI governance processes can help teams evaluate the wider implications of the proposed system.

Recording these decisions early gives engineers and governance teams a shared starting point.

2. Development and testing

Security reviews and AI evaluations should reflect the characteristics of the system being developed.

For example, an engineering team might test authentication, authorization, dependency vulnerabilities, and secrets management. It may also need to evaluate AI-specific concerns such as inappropriate outputs, performance limitations, or the effectiveness of human oversight.

The required evaluations depend on the system's purpose, risks, and applicable requirements.

Teams should document what was tested, what the results showed, and which issues remain unresolved. Where approval is required, the process should identify the responsible reviewer.

3. Deployment and change management

An AI system can change when its model, prompts, datasets, dependencies, or surrounding application is modified.

A conventional software release process can provide useful controls for reviewing and approving these changes. However, organizations should determine whether their existing process adequately captures AI-related risks.

A change that appears minor from an engineering perspective might affect output quality or the system's intended use.

Teams can establish proportionate review criteria to determine when additional testing, risk assessment, or approval is needed before a change reaches production.

4. Production monitoring

Deployment does not eliminate the need for oversight.

Engineering teams typically monitor availability, latency, errors, and infrastructure performance. Depending on the application, they may also need to evaluate output quality, recurring failure patterns, user feedback, and other AI-specific indicators.

Monitoring responsibilities should be clear. Teams need to know who reviews findings, how issues are escalated, and when corrective action is required.

The monitoring process should also reflect the organization's documented risk assessments and relevant management-system requirements.

Build a Shared Evidence Process

One of the practical challenges in implementing multiple management systems is keeping records consistent.

Security teams may maintain risk registers, engineering teams may store test results in development tools, and compliance teams may manage approvals in separate documents.

When these records are disconnected, it becomes harder to understand which decisions have been made and whether the required actions are complete.

A shared evidence process can improve traceability.
For each AI system, an organization might maintain links to:
The system's owner and intended purpose.
Relevant information security and AI risk assessments.
Testing results and review records.
Approved changes and deployment decisions.
Monitoring findings and corrective actions.

This does not mean every record must be stored in one application. The important point is that the organization can locate the evidence, identify its owner, and understand which requirements it supports.

Shared evidence should not be mistaken for identical requirements. A security test may support an information security control without demonstrating that an AI-specific assessment has been completed.

Make Responsibilities Clear Across Teams

Effective governance depends on cooperation between people who have different responsibilities.

Developers understand the implementation. Security professionals focus on protecting systems and information. Product owners understand intended use and business priorities. Compliance personnel help interpret applicable requirements and coordinate evidence.

These responsibilities can overlap, but they should not remain ambiguous.

A practical responsibility model should clarify who:

Identifies and documents AI systems.
Conducts or coordinates risk assessments.
Implements technical and organizational controls.
Reviews and approves relevant decisions.
Monitors the system and manages corrective actions.

The model should reflect the organization's size and operating structure. Smaller teams may assign several responsibilities to one person, while larger organizations may require more formal review and escalation processes.

What matters is that decisions have clear ownership and that the people responsible have the necessary competence and authority.

How Does This Relate to the EU AI Act?

Organizations operating in Europe may also need to consider obligations under the EU AI Act.

The Act's requirements depend on factors including the organization's role, the AI system's intended purpose, and its classification under the legislation.

ISO 27001 and ISO 42001 can support relevant governance activities, but neither standard automatically establishes compliance with every applicable EU AI Act requirement.

Organizations should assess their legal obligations separately and determine how existing management-system processes can support the required controls, documentation, and oversight.

This distinction is particularly important when teams use certification as evidence of a broader governance programme. A management-system certificate and a legal conformity assessment serve different purposes.

For a closer look at how the two standards complement one another, see this guide to integrating ISO 27001 and ISO 42001.

A Practical Starting Point for Engineering Teams

Organizations do not need to redesign every engineering workflow at once.

A sensible starting point is to select one AI system and map its lifecycle, existing security controls, governance responsibilities, and available evidence.

Next, identify where the current workflow does not address the relevant AI management requirements. Prioritize the gaps according to their significance, assign owners, and document the changes needed.

Once the process has been reviewed, the organization can apply the lessons to other AI systems where appropriate.

This approach helps teams build on existing capabilities without assuming that a single workflow will suit every AI application.

Conclusion

ISO 27001 and ISO 42001 can support a more coordinated approach to information security and AI governance.

Their value becomes clearer when management-system requirements connect with practical activities such as development reviews, change management, risk assessment, evidence collection, and production monitoring.

The objective is not to add unnecessary approval steps to software development. It is to make responsibilities visible, address relevant risks, and maintain records that support informed decisions.

By bringing engineering, security, and governance teams into the same process, organizations can make AI oversight a more consistent part of how their systems are developed and maintained.

AI Literacy Documentation Under the EU AI Act: A Practical Guide for AI Teams

AnnexOps — Mon, 19 Oct 2026 11:44:42 +0000

AI literacy is becoming an important part of responsible AI development and deployment. As organisations integrate AI into their products and workflows, employees need to understand how these systems work, where their limitations lie and what risks they may introduce.

Article 4 of the EU AI Act addresses this issue by requiring providers and deployers of AI systems to take measures to ensure, to their best extent, a sufficient level of AI literacy among their staff and other people dealing with AI systems on their behalf.

For engineering teams, compliance teams and AI product managers, this raises a practical question: how should an organisation organise its AI literacy activities and document its approach?

1. Start with an AI system inventory

Before planning training, identify the AI systems used or developed across the organisation.

For each system, consider recording:
System name and intended purpose
Business or technical owner
Teams and people interacting with the system
Relevant operational risks
Existing guidance and training needs

An AI inventory helps teams connect AI literacy activities with actual use cases rather than relying on generic training.

2. Map AI literacy needs to different roles

A developer building an AI-powered feature and an employee using a generative AI assistant have different responsibilities.

Developers may need guidance on system limitations, testing, data handling and risk management. Business users may need practical instructions on output verification, confidentiality and appropriate use.

An effective AI literacy program takes these differences into account. The right measures depend on the person's knowledge, experience, education, training and the context in which the AI system is used.

3. Maintain useful AI literacy documentation

Article 4 does not prescribe one universal training template or require a specific AI literacy certificate. However, maintaining internal records can help an organisation understand and review its approach.

Consider documenting:

The learning activities or guidance selected
The intended audience
The date and purpose of training activities
Supporting materials or evidence, where appropriate
Follow-up actions and review decisions

These are practical documentation recommendations, not a mandatory statutory checklist.

4. Review the program when AI use changes

AI systems and business workflows evolve. A new AI application, a change in intended use or a shift in employee responsibilities may create new learning needs.

Reviewing AI literacy measures when relevant changes occur helps teams keep their guidance useful. Organisations can also consider periodic reviews to identify gaps and coordinate activities across departments.

5. Connect AI literacy with broader AI governance

AI literacy is one part of a wider governance process. Organisations may also need to manage AI inventories, risk classification, technical documentation, human oversight and other applicable obligations under the EU AI Act.

AI compliance software can help organise related information and workflows, but software alone does not establish compliance. Teams still need to assess their circumstances and select appropriate measures.

Final thoughts

AI literacy documentation should reflect how an organisation approaches learning, who interacts with its AI systems and why particular measures have been selected.

A clear AI inventory, role-based learning activities and well-organised internal records can give AI teams a practical foundation for managing this work.

For a more detailed breakdown, read the full guide: AI Literacy Documentation: What Should Companies Record?

AnnexOps supports AI compliance and governance operations by helping organisations structure relevant workflows and documentation.

How to Build an AI Literacy Program Under the EU AI Act

AnnexOps — Wed, 14 Oct 2026 06:59:44 +0000

Artificial intelligence is becoming part of everyday business operations. SaaS companies use AI for customer support, software development, recruitment, data analysis, and product features. As adoption grows, organisations need to understand not only how these systems work but also the risks and responsibilities associated with their use.

Article 4 of the EU AI Act addresses this through AI literacy. It requires providers and deployers of AI systems to take measures to support AI literacy among their staff and other people dealing with the operation and use of AI systems on their behalf.

For businesses, the challenge is turning this requirement into practical guidance that employees can apply in their daily work.

An effective AI literacy program connects the AI systems an organisation uses with the people who interact with them, the risks they may encounter, and the guidance they need.

1. Identify Where Your Organisation Uses AI

Before creating training materials, identify the AI systems used across your organisation.

AI may be embedded in customer relationship management software, recruitment platforms, coding assistants, customer support tools, analytics applications, or internally developed products. Employees may also use generative AI tools independently of formal company workflows.

Start by creating an inventory that records:

The AI system and its intended purpose
The department or team using it
The internal owner responsible for the system
The people who interact with its outputs
Known limitations and potential risks
Existing policies, guidance, and training materials

This inventory helps programme owners understand where AI literacy measures may be needed.

It also provides a foundation for deciding which teams require general AI awareness and which need more specialised guidance.

For a practical starting point, use the AnnexOps AI Literacy Training Checklist. It outlines the key areas organisations should consider when planning and reviewing AI literacy activities.

2. Determine Whether Your Organisation Acts as a Provider or Deployer

The EU AI Act distinguishes between AI providers and deployers. An organisation may occupy either role, or both, depending on the systems involved and the activities it performs.

A provider generally develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark, subject to the Act's definitions.

A deployer uses an AI system under its authority, except for personal, non-professional use.

For example, a SaaS company developing and marketing its own AI-powered product may have provider responsibilities. The same company may act as a deployer when its employees use a third-party AI assistant for internal work.

These roles should be assessed in context rather than assigned once to the entire organisation.

Understanding the distinction helps businesses identify relevant responsibilities and design guidance for the people involved.
Read the AnnexOps guide on AI literacy training under Article 4 for more detail on the obligation and what employers should consider.

3. Identify Who Needs AI Literacy Measures

AI literacy should not be limited to employees who develop machine learning models or work directly in AI engineering.

Article 4 also refers to other people dealing with the operation and use of AI systems on behalf of a provider or deployer. The appropriate measures depend on factors such as people's technical knowledge, experience, education, training, and the context in which the systems are used.

Consider the different groups within your organisation:

Everyday AI users: Employees using AI assistants for writing, research, summarisation, or routine tasks may need guidance on verifying outputs, protecting confidential information, and recognising inaccurate or misleading results.

Product and engineering teams: Developers and product managers may need more specialised guidance on system limitations, testing, intended purpose, documentation, and relevant risk controls.

Managers and decision-makers: People relying on AI-generated

recommendations may need to understand the limits of automated outputs, the importance of human judgement, and when concerns should be escalated.

Compliance and legal teams: These teams may need a deeper understanding of AI governance responsibilities, applicable regulatory requirements, and the records used to manage the organisation's AI systems.

These are practical examples rather than fixed categories prescribed by Article 4.

For a closer look at the people who may fall within scope, read Who Needs AI Literacy Training Under the EU AI Act?.

4. Tailor Training to the AI Systems People Use

A general introduction to artificial intelligence can help establish a baseline, but it may not address the risks employees encounter in specific workflows.

Training should reflect how people actually use AI.
For example, employees using generative AI tools may need to understand hallucinations, inaccurate references, bias, data confidentiality, and the need to verify important outputs.

Teams using AI in recruitment or other sensitive business processes may require guidance on the system's intended purpose, relevant limitations, applicable safeguards, and the potential effects on individuals.

Developers integrating third-party models into software may need guidance on model evaluation, system documentation, monitoring, and the risks associated with changes to the underlying technology.

The European Commission's AI literacy guidance highlights the importance of considering the systems involved, people's existing knowledge and experience, and the context in which AI is used.

Organisations should therefore connect their learning measures to real tasks rather than relying exclusively on generic awareness presentations.

5. Choose Appropriate Training Formats

Article 4 does not prescribe one mandatory training format, a universal syllabus, or a minimum number of training hours.
Organisations can choose measures that fit their size, operations, and AI use cases.

Possible approaches include:

Short workshops using practical AI examples
Written policies explaining acceptable and unacceptable AI use
Role-specific learning sessions
E-learning modules and internal learning resources
Demonstrations showing how to verify AI-generated outputs
Team discussions about risks and lessons from real workflows

A smaller business may begin with concise guidance and targeted sessions for employees who use AI regularly. A larger organisation may need different learning paths for technical, managerial, operational, and compliance teams.

The objective is to provide relevant guidance that reflects the people, systems, and circumstances involved.

Organisations should review their approach periodically and update it when their AI tools, workflows, or identified risks change.

6. Record AI Literacy Activities and Review Progress

An AI literacy program needs a practical way to track what the organisation has done and where further work may be needed.

Article 4 does not prescribe a specific documentation template or require a universal AI literacy certificate. However, maintaining useful internal records can help organisations review their activities and manage the programme over time.

Consider recording:

The training or other AI literacy measures provided
The teams or groups covered
The topics and AI systems addressed
The dates and formats of learning activities
Feedback and identified knowledge gaps
Planned updates or follow-up activities

These records help programme owners understand which measures have been delivered and identify areas that need attention. They should not be treated as automatic proof that all applicable legal obligations have been satisfied.

For organisations managing multiple teams and AI systems, a structured tracking process can reduce reliance on disconnected spreadsheets and manual follow-ups.

The AnnexOps AI Literacy Compliance Tracker is designed to support AI literacy tracking and related compliance evidence management. Organisations should assess its capabilities against their own operational and documentation requirements.

7. Connect AI Literacy With Wider AI Governance

AI literacy is one part of an organisation's broader AI governance process. Training alone does not replace the need to understand the systems in use, assess relevant risks, maintain appropriate documentation, or manage applicable responsibilities.

A connected approach helps organisations link their AI literacy activities with their wider governance work.

For example, when a business introduces a new AI system, it can review who will use the system, identify relevant risks, determine what guidance those people need, and record the measures provided.

Where appropriate, the organisation can also connect this work with its AI risk classification and compliance workflows.

The AnnexOps Risk Classification Engine supports classification against EU AI Act Annex III use cases and provides confidence scoring and legal-review flagging. Risk classification and AI literacy serve different purposes, but considering them together can help organisations develop guidance that reflects the systems they use.

For a broader operational perspective, see How to Build AI Risk Management Workflows for EU AI Act Compliance at Scale.

8. Review the Programme as AI Use Changes

AI literacy should not remain a one-time training exercise.
New tools, model updates, changes to business workflows, and new AI use cases can introduce different risks and learning needs. Organisations should therefore establish a review process that considers changes in their AI portfolio and feedback from the people using those systems.

A practical review can ask:

Have new AI systems been introduced?
Are employees using existing systems in new ways?
Have relevant risks or limitations changed?
Do employees understand the guidance provided?
Are there teams that need additional support?
Should internal policies or learning materials be updated?

The frequency of review should reflect the organisation's circumstances and the nature of its AI use.

Where high-risk AI systems are involved, additional requirements may apply. For example, Article 26 contains specific obligations for deployers of high-risk AI systems, including provisions relating to human oversight. General AI literacy activities should not be treated as a substitute for these separate obligations.

How AnnexOps Supports AI Literacy and Governance

AnnexOps is AI compliance software designed to support organisations managing EU AI Act and AI governance operations.

Its AI literacy tracking capability helps organisations organise training activities and related evidence. The wider product environment also supports AI system inventory, risk classification, obligation management, documentation, evidence storage, and ongoing monitoring.

These capabilities can help teams connect AI literacy activities with the broader governance processes surrounding their AI systems. Organisations should assess their specific needs and verify which product capabilities are appropriate for their workflows.

To explore the implementation steps in more detail, read the full AnnexOps guide: How to Create an EU AI Act AI Literacy Program.

Conclusion

Building an AI literacy program starts with understanding how AI is used across the organisation. Businesses can then identify the people involved, tailor guidance to relevant systems and responsibilities, record the measures taken, and review the programme as their use of AI evolves.

Article 4 provides flexibility in how organisations support AI literacy, but the approach should reflect their actual operating context.

By integrating AI literacy into wider AI governance activities, organisations can make their guidance more relevant to everyday work and easier to maintain as their AI systems change.

ISO 42001 vs EU AI Act: Do You Need Both?

AnnexOps — Tue, 06 Oct 2026 08:47:49 +0000

As organizations adopt artificial intelligence across products, operations, and customer-facing services, AI governance is becoming a practical business requirement. Two frameworks often appear in these discussions: ISO/IEC 42001 and the EU AI Act.

At first glance, they may seem to address the same problem. Both involve AI risk management, governance, documentation, and oversight. However, they serve different purposes.

ISO 42001 provides a management-system framework for organizations that want a structured approach to managing AI-related risks. The EU AI Act is a binding European regulation that establishes legal requirements based on the risks associated with AI systems.

So, do organizations need both?

For many companies operating or placing AI systems on the European market, using both can provide a stronger governance structure. But ISO 42001 certification does not automatically mean that an organization has met its EU AI Act obligations.

ISO 42001 and the EU AI Act Serve Different Purposes

The simplest way to understand the difference is to look at what each framework is designed to accomplish.

ISO/IEC 42001 is an international standard for an Artificial Intelligence Management System (AIMS). It helps organizations establish processes for managing AI responsibly across their operations.

The EU AI Act, meanwhile, is legislation. It uses a risk-based approach and establishes obligations for different AI systems and actors, including providers and deployers.

The distinction matters because implementing a management system is not the same as demonstrating compliance with a specific law.

For example, an organization may have a mature AI governance process under ISO 42001 but still need to determine whether individual AI systems fall into categories covered by the EU AI Act.

The EU AI Act specifically defines requirements for high-risk AI systems, including risk management, data governance, technical documentation, record-keeping, transparency, human oversight, and other controls.

What Does ISO 42001 Provide?

ISO 42001 gives organizations a structured management approach for AI.

Instead of treating AI governance as a collection of disconnected policies, an AI management system can connect responsibilities, processes, risk assessment, objectives, monitoring, and continual improvement.

This can be useful for organizations that operate multiple AI systems or integrate AI into different business functions.

An ISO 42001 implementation can help establish:

AI governance responsibilities
AI risk management processes
Internal policies and controls
Documentation practices
Monitoring and review processes
Continual improvement
Organizational accountability

The value is not limited to regulatory compliance. A structured management system can also help organizations create repeatable processes as their AI portfolio grows.

However, ISO 42001 should not be treated as a substitute for understanding applicable legal requirements.

What Does the EU AI Act Require?

The EU AI Act takes a different approach.

Rather than simply asking whether an organization has an AI management system, the regulation considers the characteristics and use of AI systems and assigns obligations according to risk.

For example, Article 6 establishes rules for identifying certain high-risk AI systems, including systems covered by Annex I legislation and systems listed in Annex III.

For high-risk AI systems, the regulation requires a documented and maintained risk management system throughout the system lifecycle. It also addresses areas such as data governance, technical documentation, logging, transparency, human oversight, and post-market monitoring.

This means an organization needs more than a general AI governance policy. It needs to understand how the regulation applies to its specific systems, roles, uses, and obligations.

ISO 42001 Certification Does Not Equal EU AI Act Compliance

This is one of the most important distinctions.

ISO 42001 certification is not the same thing as EU AI Act compliance.
Certification demonstrates that an organization's AI management system has been assessed against the requirements of ISO 42001. It does not automatically establish that every AI system operated or provided by that organization satisfies the applicable requirements of the EU AI Act.

The reverse is also important.

An organization can work toward EU AI Act compliance without pursuing ISO 42001 certification.

Therefore, companies should avoid treating one framework as a replacement for the other.

Instead, it is more useful to consider where the two approaches overlap and where they remain distinct.

Where ISO 42001 and the EU AI Act Overlap

There is significant practical overlap between AI management systems and EU AI Act compliance activities.

Both can involve:

Risk management: Organizations need processes for identifying, assessing, and addressing AI-related risks.

Governance: Clear responsibilities and accountability are important for managing AI systems.

Documentation: Organizations need reliable records showing how AI systems are managed and controlled.

Monitoring: AI governance does not end when a system is deployed. Ongoing review is important.

Continual improvement: AI systems, risks, business processes, and regulatory expectations can change over time.

The EU AI Act itself requires a lifecycle-oriented risk management system for high-risk AI systems, with regular review and updating.

This creates an opportunity to design internal processes that support both frameworks rather than maintaining completely separate systems.

Why High-Risk AI Systems Need Extra Attention

The question becomes more important when an organization develops or deploys high risk AI systems.

High-risk systems are subject to specific requirements under the EU AI Act. For providers, these can include a quality management system, documentation, logs, conformity assessment, registration, and other obligations.

Organizations therefore need a practical way to answer questions such as:

Which AI systems are being used?
What is each system's intended purpose?
Is the organization a provider or deployer?
Does the system fall into a high-risk category?
Which obligations apply?
What documentation is required?
What evidence demonstrates that controls are operating?
How will the system be monitored after deployment?

These questions go beyond simply having an AI policy.

Can One AI Governance Process Support Both?

Yes.

A practical approach is to create an integrated governance process.
Start by building an inventory of AI systems and recording information such as ownership, purpose, use case, provider or deployer role, and risk classification.

Next, map the relevant governance controls and regulatory obligations to each system.

For systems that fall within the EU AI Act, the organization can then identify applicable requirements and connect them to documentation, controls, responsible teams, and evidence.

This approach can reduce duplicated work.

For example, an organization may already maintain risk assessment procedures under its AI management system. Instead of creating a completely separate risk process for the EU AI Act, the existing process can be extended to capture the information needed for applicable regulatory requirements.

The key is to maintain a clear distinction between management-system controls and legal obligations.

Where an AI Audit Platform Can Help

As AI portfolios expand, spreadsheets and disconnected documents can become difficult to manage.

An AI audit platform can provide a centralized environment for tracking AI systems, risk classifications, obligations, documentation, evidence, and review activities.

This is particularly useful when teams need to demonstrate how a decision was made and what evidence supports it.

A centralized workflow can connect:

AI inventory → risk classification → applicable obligations → controls → documentation → evidence → monitoring

This type of workflow can support both broader AI governance activities and EU AI Act compliance operations.

It can also make internal reviews more consistent by giving compliance, legal, product, and technical teams a shared view of AI-related responsibilities.

Building an AI Compliance Operation

An effective AI Compliance Operation should not depend on a single annual review.

AI systems change. Models are updated. Intended purposes can evolve. New systems may be introduced. Regulatory requirements can also develop over time.

For this reason, organizations should consider compliance as an ongoing operational process.
A mature operation can include:

AI system inventory management
Risk classification
Obligation tracking
Documentation management
Evidence collection
Internal reviews
Audit preparation
Continuous monitoring

This also makes it easier to identify gaps before they become urgent compliance problems.

Should You Implement ISO 42001 or the EU AI Act First?

There is no universal sequence.

The right starting point depends on the organization's AI portfolio, regulatory exposure, customers, governance maturity, and business objectives.

If the immediate priority is understanding legal exposure in Europe, an organization may first map its AI systems against the EU AI Act.

If the organization wants to establish a broader AI management framework across departments, ISO 42001 may provide a useful structure.

For some organizations, implementing both in parallel may be the most efficient approach.

The important point is to avoid building two completely disconnected compliance programs.

How to Combine Both Frameworks

A practical implementation can follow this structure:

1. Create an AI inventory
Identify the AI systems used, developed, purchased, or integrated across the organization.

2. Classify AI systems
Assess each system based on its intended purpose, role, use context, and applicable regulatory classification.

3. Map legal obligations
For systems within the scope of the EU AI Act, identify the applicable requirements and responsibilities.

4. Connect governance controls
Map organizational policies, risk controls, review processes, and responsibilities to the relevant systems.

5. Maintain evidence
Store documentation and evidence in a structured way so teams can demonstrate what was assessed, approved, changed, or monitored.

6. Monitor continuously
Review systems as they change rather than treating compliance as a one-time project.

This approach creates a bridge between organizational AI governance and regulatory compliance.

Do You Need Both?

Not every organization needs ISO 42001 certification.

Likewise, not every organization will have the same EU AI Act obligations.
However, organizations using AI at scale may benefit from combining a structured AI management system with a regulatory compliance process.

ISO 42001 can provide a framework for organizational AI governance. The EU AI Act provides legally binding requirements that depend on the AI system, its intended purpose, and the organization's role.

The two should therefore be viewed as complementary rather than interchangeable.

For organizations managing multiple AI systems, an integrated AI compliance software approach can help connect governance processes with risk classification, regulatory obligations, documentation, evidence, and ongoing monitoring.

AnnexOps takes this operational approach by helping organizations connect AI governance and EU AI Act compliance activities within a structured workflow.

Final Takeaway

ISO 42001 and the EU AI Act answer different questions.

ISO 42001 asks how an organization can establish and maintain a structured management system for AI.

The EU AI Act asks what legal requirements apply to AI systems based on their risk, role, and use.

Using both does not necessarily mean maintaining two separate compliance programs. With the right processes, organizations can align AI governance, risk management, documentation, and monitoring while separately tracking the legal obligations that apply to specific AI systems.

For companies developing or deploying AI in Europe, the better question may not be “ISO 42001 or EU AI Act?”

It may be “How can we build one effective AI governance operation that supports both?”

Einbindung von KI-Compliance in den Entwicklungslebenszyklus

AnnexOps — Wed, 16 Sep 2026 07:45:40 +0000

KI-Funktionen finden immer schneller den Weg vom Experiment in die Produktionssoftware. Für Entwicklungs- und Produktteams wirft das eine praktische Frage auf:

Wie behalten Sie den Überblick über KI-Systeme, deren Risiken, Dokumentation und Compliance-Anforderungen, während sich das Produkt weiterentwickelt?

Für in Europa tätige Unternehmen gewinnt diese Frage durch das EU-KI-Gesetz zunehmend an Bedeutung. AnnexOps beschreibt das Jahr 2026 als eine neue Phase der Durchsetzung des KI-Gesetzes, in der Unternehmen die geltenden Anforderungen in Bestandsaufnahmen, Risikobewertungen, Kontrollmaßnahmen, Dokumentation, Nachweise, Zuständigkeiten und Überwachungsprozesse umsetzen müssen.

Das Problem, wenn Compliance als separate Aufgabe behandelt wird

Ein typischer Entwicklungsablauf sieht in etwa so aus:

Eine KI-Funktion entwickeln.
Testen.
Es bereitstellen.
Später dokumentieren.

Die Compliance kann zu einem zusätzlichen Prozess werden, der erst nach der Entwicklung stattfindet.

Dadurch entsteht eine Diskrepanz zwischen den KI-Systemen, die Ingenieure tatsächlich entwickeln, und den Informationen, die Compliance-Teams benötigen.

Ein besserer Ansatz besteht darin, die KI-Governance mit dem Systemlebenszyklus zu verknüpfen.

Der erste Schritt besteht darin, zu erfassen, welche KI-Systeme im gesamten Unternehmen vorhanden sind.

Beginnen Sie mit einer KI-Bestandsaufnahme

KI kann in kundenorientierten Produkten, internen Anwendungen, SaaS-Funktionen oder Diensten von Drittanbietern vorkommen.

Ein Unternehmen benötigt daher einen klaren Überblick über seine KI-Infrastruktur.

Ein KI-Bestandsverzeichnis kann Teams dabei helfen, Systeme zu erfassen und mit Informationen wie den folgenden zu verknüpfen:

● Verwendungszweck
● Risikoklassifizierung
● Rolle des Anbieters oder Betreibers
● Geltende Verpflichtungen
● Dokumentation
● Nachweis der Einhaltung
● Verantwortlichkeit
● Überwachungsstatus

Dies bietet den Teams aus den Bereichen Technik, Produktentwicklung, Sicherheit und Compliance einen gemeinsamen Überblick über die Systeme, für die sie verantwortlich sind.

Die Risikoklassifizierung geht der Checkliste voraus

Nicht jedes KI-System unterliegt denselben regulatorischen Anforderungen.

Das EU-KI-Gesetz verfolgt einen risikobasierten Ansatz, was bedeutet, dass Unternehmen zunächst verstehen müssen, in welche Kategorie ihre Systeme fallen, bevor sie entscheiden können, welche Compliance-Maßnahmen erforderlich sind.

Für Entwicklungsteams macht dies die Risikoklassifizierung zu einem wichtigen Bestandteil des Entwicklungsworkflows.

Anstatt eine generische Checkliste für jede KI-Funktion zu führen, können Teams die Anforderungen an das jeweilige System und dessen Verwendungszweck anpassen.

Die Dokumentation sollte sich am System orientieren

Technische Dokumentation und Nachweise zur Einhaltung der Vorschriften sollten nicht erst in letzter Minute erstellt werden.

Da sich KI-Systeme weiterentwickeln, müssen Teams die damit verbundenen Informationen möglicherweise aktualisieren.

Beispielsweise kann eine Änderung des Zwecks oder des Einsatzkontexts einer KI-Funktion erfordern, dass Teams die bestehende Bewertung und Dokumentation überprüfen.

Wenn die Compliance-Informationen mit dem System verknüpft bleiben, lassen sich diese Änderungen leichter nachverfolgen.

Die Überwachung endet nicht mit der Bereitstellung

Die Bereitstellung ist nicht das Ende der KI-Governance.

KI-Systeme können sich durch Modellaktualisierungen, neue Daten, neue Funktionen oder Änderungen in der Art und Weise, wie Nutzer mit ihnen interagieren, verändern.

AnnexOps bietet Funktionen zur kontinuierlichen Überwachung, die Unternehmen dabei unterstützen sollen, KI-Systeme zu überwachen und Compliance-Nachweise langfristig zu pflegen. Die Plattform umfasst zudem eine KI-Auditor-Engine für automatisierte Bereitschaftsprüfungen und Lückenanalysen.

Dadurch entsteht ein Workflow, der über die reine Speicherung von Compliance-Dokumenten hinausgeht.

Wo KI-Compliance-Software zum Einsatz kommt

Hier kann KI-Compliance-Software technische und Governance-Workflows miteinander verbinden.

AnnexOps bietet unter anderem folgende Funktionen:

● Risikoklassifizierungs-Engine
● Verpflichtungs-Engine
● Dokumentengenerator
● Nachweis-Archiv
● Kontinuierliche Überwachung
● KI-Audit-Engine
● DSGVO-KI-Gesetz-Engine
● Entwickler-SDK
● Compliance-API
● CI/CD-Integrationen

Ziel ist es, Unternehmen dabei zu unterstützen, KI-Systeme zu identifizieren, regulatorische Risiken einzustufen, Compliance-Kontrollen zu automatisieren und sich auf Audits vorzubereiten.

Für Entwicklungsteams sind die entwicklerorientierten Funktionen besonders relevant, da Compliance-Aktivitäten enger mit bestehenden technischen Arbeitsabläufen verknüpft werden können.

Ein praktischer Workflow für Entwicklerteams

Ein einfacher KI-Compliance-Workflow könnte wie folgt aussehen:

Identifizieren → Klassifizieren → Verpflichtungen zuordnen → Dokumentieren → Nachweise sammeln → Überwachen → Überprüfen

Wichtig ist, dass diese Schritte miteinander verknüpft bleiben.

Wenn sich ein System ändert, sollten die zugehörigen Compliance-Informationen überprüfbar sein, anstatt in einem veralteten Dokument oder einer Tabelle zu verbleiben.

Fazit

KI-Compliance wird für Entwicklungs- und Produktteams zu einer operativen Herausforderung und ist nicht mehr nur eine reine Dokumentationsaufgabe.

Die Herausforderung besteht darin, KI-Systeme, Risikobewertungen, Verpflichtungen, Nachweise und die Überwachung im Zuge der Produktentwicklung miteinander zu verknüpfen.

Für Unternehmen, die einen strukturierteren KI-Governance-Workflow aufbauen möchten, bietet AnnexOps KI-Compliance-Software an, die auf die Erfassung von KI-Systemen, Risikoklassifizierung, Dokumentation, Nachweismanagement, Audits und kontinuierliche Überwachung ausgelegt ist.

Building AI Compliance Into the Development Lifecycle

AnnexOps — Wed, 16 Sep 2026 07:28:59 +0000

AI features are moving quickly from experiments into production software. For engineering and product teams, that creates a practical question:

How do you keep track of AI systems, their risks, documentation, and compliance requirements as the product changes?

For organizations operating in Europe, the EU AI Act makes this question increasingly important. AnnexOps describes 2026 as a new phase of AI Act enforcement, with organizations needing to translate applicable requirements into inventories, risk assessments, controls, documentation, evidence, ownership, and monitoring processes.

The Problem With Treating Compliance as a Separate Task

A common development workflow looks something like this:

Build an AI feature.
Test it.
Deploy it.
Document it later.

Compliance can become an additional process that happens after development.

That creates a disconnect between the AI systems engineers are actually building and the information compliance teams need.

A better approach is to connect AI governance with the system lifecycle.
The first step is knowing what AI systems exist across the organization.

Start With an AI Inventory

AI can appear in customer-facing products, internal applications, SaaS features, or third-party services.

An organization therefore needs a clear view of its AI estate.
An AI inventory can help teams track systems and connect them with information such as:

Intended purpose
Risk classification
Provider or deployer role
Applicable obligations
Documentation
Compliance evidence
Ownership
Monitoring status

This gives engineering, product, security, and compliance teams a shared view of the systems they are responsible for.

Risk Classification Comes Before the Checklist

Not every AI system has the same regulatory requirements.

The EU AI Act uses a risk-based approach, which means organizations need to understand where their systems fit before deciding what compliance work is required.

For engineering teams, this makes risk classification an important part of the development workflow.

Instead of maintaining one generic checklist for every AI feature, teams can connect requirements to the specific system and its intended use.

Documentation Should Follow the System

Technical documentation and compliance evidence should not become a last-minute exercise.

As AI systems evolve, teams may need to update the information associated with them.

For example, a change in an AI feature's purpose or deployment context can require teams to review its existing assessment and documentation.

Keeping compliance information connected to the system makes those changes easier to track.

Monitoring Doesn't End at Deployment

Deployment is not the end of AI governance.

AI systems can change through model updates, new data, new functionality, or changes in how users interact with them.

AnnexOps provides continuous monitoring capabilities designed to help organizations monitor AI systems and maintain compliance evidence over time. Its platform also includes an AI Auditor Engine for automated readiness checks and gap analysis.

This creates a workflow that goes beyond storing compliance documents.

Where AI Compliance Software Fits

This is where AI compliance software can connect technical and governance workflows.

AnnexOps provides capabilities including:

Risk Classification Engine
Obligation Engine
Document Generator
Evidence Vault
Continuous Monitoring
AI Auditor Engine
GDPR–AI Act Engine
Developer SDK
Compliance API
CI/CD integrations

The goal is to help organizations discover AI systems, classify regulatory risk, automate compliance controls, and prepare for audits.

For development teams, the developer-oriented capabilities are particularly relevant because compliance activities can be connected more closely with existing technical workflows.

A Practical Workflow for Engineering Teams

A simple AI compliance workflow can look like this:

Discover → Classify → Map obligations → Document → Collect evidence → Monitor → Review

The important part is that these steps remain connected.

When a system changes, the related compliance information should be reviewable rather than remaining in an outdated document or spreadsheet.

Final Takeaway

AI compliance is becoming an operational concern for engineering and product teams, not just a documentation exercise.

The challenge is keeping AI systems, risk assessments, obligations, evidence, and monitoring connected as products evolve.

For organizations looking to build a more structured AI governance workflow, AnnexOps provides AI compliance software designed around AI system discovery, risk classification, documentation, evidence management, auditing, and continuous monitoring.

EU AI Act Annex III Deadline 2027: What Developers and AI Teams Should Know

AnnexOps — Wed, 09 Sep 2026 07:49:07 +0000

The EU AI Act is entering a more operational phase in 2026, but one of the biggest compliance milestones for high-risk AI systems is now scheduled for 2 December 2027.

The change is particularly important for companies developing or deploying AI in areas such as employment, education, credit, biometrics, critical infrastructure, law enforcement, migration, and other sensitive use cases.
The revised timeline gives organizations more time to prepare for the EU AI Act Annex III deadline 2027. But more time does not necessarily mean less work.

For development and compliance teams, this is an opportunity to build AI governance into the product lifecycle instead of trying to retrofit compliance shortly before the deadline.

## What Is Annex III?

Annex III of the EU AI Act identifies categories of AI systems that can be considered high-risk because of their potential impact on health, safety, fundamental rights, or access to important opportunities.

Examples include AI systems used for:

Recruitment and employment decisions
Education and vocational training
Creditworthiness and access to essential services
Biometric identification and categorisation
Critical infrastructure
Law enforcement
Migration, asylum, and border control
Administration of justice and democratic processes

Not every AI system used in these sectors is automatically high-risk. The specific intended purpose and applicable classification criteria need to be assessed.

This is why AI inventory and classification are becoming increasingly important for engineering and compliance teams.

## What Changed About the 2027 Deadline?

Under the updated implementation timeline, the rules for high-risk AI systems covered by Annex III are scheduled to apply from 2 December 2027. The European Commission also distinguishes these systems from certain high-risk AI systems embedded in regulated products, for which the relevant rules are scheduled to apply from 2 August 2028.

The timeline changed following the EU's AI Omnibus amendments, which entered into force in July 2026.

This gives companies additional preparation time.

However, the deadline should not be interpreted as:

"We have until December 2027, so we can start compliance in November 2027."
High-risk AI compliance can involve technical documentation, risk management, data governance, human oversight, monitoring, record keeping, cybersecurity, and other controls. Building these processes across multiple AI systems can take considerable time.

Why Developers Should Care About Annex III

EU AI Act compliance is not only a legal or compliance-team responsibility.

For developers, many of the required controls can affect how an AI system is designed, tested, documented, deployed, and monitored.

For example, a team building an AI recruitment system may need to think about:

What is the intended purpose of the system?
What data is being used?
How is the model evaluated?
What risks could affect candidates?
Where is human oversight required?
How are model changes documented?
What happens when the model produces an unexpected result?
What evidence exists to demonstrate that controls were implemented?

These questions are much easier to answer when governance is integrated into the development lifecycle.

A Practical Preparation Plan for 2027

Instead of waiting for the deadline, organizations can use the additional time to establish a repeatable compliance workflow.

1. Create an AI inventory

Start by identifying the AI systems your organization develops, purchases, integrates, or deploys.

Your inventory might include:

Internal machine-learning models
AI features inside SaaS products
Third-party AI APIs
Recruitment or HR AI tools
Credit and financial decision systems
Computer vision applications
Generative AI systems
AI-powered recommendation engines

Without an accurate inventory, it is difficult to determine which systems require further assessment.

2. Classify AI systems

Once your inventory exists, determine which systems could fall within the EU AI Act's high-risk categories.

Classification should consider the system's actual intended purpose rather than simply asking whether the product uses AI.

The European Commission has published guidance aimed at helping providers and deployers assess whether AI systems should be classified as high-risk.

3. Map requirements to each system

Different AI systems may have different obligations.

For potentially high-risk systems, organizations should begin mapping requirements such as:

Risk management
Data and data governance
Technical documentation
Record keeping
Human oversight
Accuracy and robustness
Cybersecurity
Quality management
Post-market monitoring

The objective is to create a clear connection between a regulatory requirement and the control or process used to address it.

4. Build documentation during development

Documentation should not be something developers create only when an auditor asks for it.

For high-risk AI, technical documentation is an important part of demonstrating how the system was designed and governed.

A practical approach is to capture relevant information throughout development:

Requirement → Design decision → Test → Evidence → Review

This makes compliance evidence easier to maintain as the system changes.

5. Monitor changes continuously

AI systems are rarely static.

Models can be retrained. Datasets can change. Vendors can update APIs. Features can be added. Deployment environments can change.

Therefore, an AI compliance process should account for these changes.

A useful workflow is:

AI change → Risk review → Compliance impact → Documentation update → Evidence

This approach is much more sustainable than performing a single compliance assessment before December 2027.

The 2027 Deadline Is a Preparation Window

The most useful way to think about the EU AI Act Annex III deadline is not as a date to work backward from, but as a target for having your governance processes operational.

Organizations can use the additional time to:

Discover their AI systems.
Identify potentially high-risk use cases.
Classify systems consistently.
Map regulatory obligations.
Establish risk-management processes.
Build technical documentation.
Assign human oversight responsibilities.
Maintain evidence throughout the AI lifecycle.
Monitor systems after deployment.

This is especially important for companies with many AI applications or third-party AI dependencies.

What About Article 50?

It is also important not to confuse the 2027 Annex III deadline with the EU AI Act's transparency requirements.

Article 50 transparency obligations became applicable from 2 August 2026, covering areas such as certain AI-generated or manipulated content, AI interactions, deepfakes, and specific biometric or emotion-recognition use cases.

In other words, the EU AI Act does not have a single "2027 compliance date."

Different obligations apply at different times.

That makes maintaining a regulatory timeline particularly important for AI teams.

A Simple Compliance Architecture for AI Teams

For organizations building AI products, a practical compliance workflow could look like this:

AI Inventory
↓
Risk Classification
↓
Applicable Requirements
↓
Risk Assessment
↓
Controls & Documentation
↓
Testing & Evidence
↓
Deployment
↓
Continuous Monitoring
↓
Periodic Review

The advantage of this approach is that compliance becomes part of the AI lifecycle rather than a separate administrative process.

How AI Compliance Software Can Help

Managing one AI system manually may be possible.

Managing dozens or hundreds of AI systems, vendors, models, documents, assessments, and evidence is considerably harder.

This is where AI compliance software can help organizations centralize their AI inventory, risk assessments, compliance obligations, documentation, and evidence.

For teams preparing specifically for the 2027 milestone, Annex III EU AI Act deadline 2027 provides a useful overview of the revised timeline and what organizations should do during the preparation period.

The broader goal should not simply be to "pass" an EU AI Act assessment.

It should be to build an AI governance process that can keep working as your models, vendors, products, and regulatory obligations evolve.

Final Thoughts

The EU AI Act Annex III deadline 2027 gives organizations more time to prepare for high-risk AI requirements.

That additional time is valuable, but only if companies use it.

For developers and AI product teams, preparation can start with relatively practical steps: build an AI inventory, understand intended purposes, assess risk, map requirements, document important decisions, and preserve evidence throughout the AI lifecycle.

By the time 2 December 2027 arrives, organizations that have already built these processes will be in a much stronger position than those treating the deadline as a last-minute compliance project.

The key takeaway is simple:

Don't wait for the deadline to build your AI governance infrastructure. Build it before the deadline becomes a problem.

EU AI Act Compliance: What Businesses Need to Know

AnnexOps — Thu, 03 Sep 2026 08:30:32 +0000

AI has moved from being an experimental technology to becoming part of everyday business. Companies now use AI for recruitment, customer support, fraud detection, content creation, healthcare, finance, and many other activities.

But as AI use grows, so does the need for responsible management.

For businesses operating in or serving the European market, EU AI Act Compliance is becoming an important part of AI strategy. The regulation does not treat every AI system in the same way. Instead, it follows a risk-based approach. The level of responsibility depends on how an AI system is used and the potential impact it can have on people.

This creates an important challenge for businesses. They need to understand which AI systems they use, what risks those systems may create, and what requirements apply to them.

Why Businesses Need to Look Beyond AI Adoption

Many companies have adopted AI faster than they have built processes to manage it. Different teams may use different AI tools without a central record of what is being used.

For example, a marketing team may use a generative AI tool for content. An HR team may use software that supports recruitment. Customer service may rely on an AI chatbot, while developers may integrate an external AI model into a product.

Each use case can have different implications.

Without a clear view of these systems, it becomes difficult to answer basic questions. Which AI tools are being used? Who owns them? What data do they process? What decisions do they support? Are they supplied by a third party? What risks could they create?

This is why AI governance should start with visibility.

A basic AI inventory can help businesses create that visibility. It can record the AI system, its purpose, provider, owner, users, business function, and other relevant details. Once this information is available, organizations can begin assessing which systems need closer attention.

This approach also makes EU AI Act Compliance more practical. Instead of trying to understand the entire regulation at once, businesses can assess their actual AI landscape and focus their efforts where they matter most.

Risk Classification Makes a Difference

One of the most important ideas behind the EU AI Act is risk.

Not every AI system presents the same level of concern. Some uses may create limited risks, while others can have a significant effect on people's rights, safety, or opportunities.

This is where risk classification becomes important.

Businesses should look at what an AI system does, why it is being used, and the context in which it operates. The same type of technology can create different regulatory concerns depending on its purpose.

Consider recruitment as an example. An AI tool that helps write a job description is very different from a system that evaluates candidates or influences hiring decisions.

The technology may be AI in both cases, but the potential impact is not the same.

High-risk AI systems require particular attention because they can be subject to more detailed requirements under the EU AI Act. Depending on the system and the organization's role, areas such as risk management, documentation, human oversight, record keeping, and monitoring may become important.

Businesses should therefore avoid making risk decisions based only on the name of an AI product. The actual use case matters.

Risk classification should also be reviewed when an AI system changes. A company may introduce a new feature, connect the system to another business process, or start using it for a different purpose. These changes can affect the original assessment.

Keeping risk information updated is therefore more useful than completing a classification exercise once and forgetting about it.

Third-Party AI Creates Another Challenge

Businesses do not always build their AI systems themselves.

Many companies rely on AI features provided by SaaS platforms, cloud services, APIs, and other vendors. This can make compliance more complicated because an organization may use an AI capability without knowing exactly how it works or what responsibilities belong to the provider and the deployer.

Third-party AI should therefore be included in the organization's AI inventory.

Businesses should understand what the vendor provides, how the system is being used internally, and what information is available about its risks and controls. Contractual responsibilities should also be reviewed where relevant.

This is especially important when AI is used in business processes that can affect employees, customers, applicants, or other individuals.

A vendor may provide technical documentation, but the organization using the system still needs to understand its own responsibilities.

Good vendor governance does not mean avoiding third-party AI. It means knowing where it is being used and having enough information to manage the associated risks.

Turning Compliance Into an Ongoing Process

One of the biggest mistakes businesses can make is treating compliance as a document that is completed once.

AI systems change. Vendors update their models. New features are introduced. Employees adopt new tools. Business processes evolve.

As a result, compliance needs to keep pace.

This is where an AI compliance operation can make a difference. Instead of managing AI information across disconnected spreadsheets, emails, and documents, businesses can create a repeatable process for managing their AI systems.

A practical process can include several simple steps.

First, identify the AI systems being used across the organization. Next, assign an owner to each system and record its purpose. Then assess the relevant risks and obligations. After that, document the controls and evidence supporting the assessment.

The process should not end there.

Organizations should review their AI systems periodically and whenever significant changes occur. Evidence should also be kept up to date so teams can explain how a particular AI system was assessed and managed.

This creates a more useful form of governance. Instead of reacting whenever a compliance question appears, the organization already has a structured record of its AI environment.

Technology can support this process by bringing AI inventory, risk classification, compliance obligations, documentation, and monitoring into one workflow. Platforms such as AnnexOps are designed to help organizations manage these activities as part of an ongoing AI governance process.

What Should Businesses Do First?

Companies do not need to build a complicated AI governance program overnight.

A practical starting point is to understand what already exists.

Begin by creating an inventory of AI systems used across departments. Include internally developed systems as well as third-party tools and AI features built into existing software.

Next, identify who is responsible for each system. The owner should be able to explain what the system does, why it is being used, and how it fits into the business process.

The next step is risk classification. Review the purpose and use of each system and identify whether additional requirements may apply.

Businesses should then map the relevant obligations and identify any gaps. Where documentation or controls are missing, those areas can be prioritized.

Finally, create a process for ongoing review.

This last step is often overlooked. A compliance program that works today may not be enough six months from now if the AI system, vendor, or business process has changed.

A structured approach allows organizations to scale their governance as their use of AI grows.

What This Means for Businesses

The EU AI Act is not simply another regulation for businesses to add to their compliance checklist. It reflects a broader shift in how organizations are expected to manage artificial intelligence.

Companies need to understand the systems they use. They need to assess the risks those systems create. They also need clear ownership, appropriate controls, reliable documentation, and ongoing monitoring.

For businesses, this can be an opportunity rather than only a regulatory burden.

A well-managed AI environment can improve internal visibility, support responsible AI adoption, and make it easier to respond to customer, auditor, or regulatory questions.

Most importantly, EU AI Act Compliance becomes easier to manage when it is connected to everyday AI operations instead of being treated as a separate legal exercise.

As AI becomes more deeply integrated into business, organizations that build good governance practices early will be better positioned to manage both regulatory requirements and the practical risks that come with AI adoption.

Learn how AnnexOps can support your EU AI Act Compliance journey.
👉 Explore AnnexOps

AI Governance for HR: Preparing Recruitment Teams for the EU AI Act

AnnexOps — Thu, 20 Aug 2026 09:31:59 +0000

Artificial intelligence is transforming how companies find, evaluate, and hire talent. Recruitment teams increasingly use AI to screen resumes, rank candidates, match skills, analyze interviews, and recommend potential hires at a scale that would be difficult to achieve manually.

But as AI becomes embedded in hiring workflows, efficiency is no longer the only consideration. Organizations also need to understand whether these systems can be governed, monitored, explained, and documented appropriately.

For companies operating in Europe or providing AI-powered recruitment solutions to European customers, this is becoming a strategic priority.

The EU AI Act places certain AI systems used in employment and recruitment within the high-risk category, bringing additional expectations around risk management, transparency, human oversight, technical documentation, and accountability.

For HR leaders, CTOs, compliance teams, AI product leaders, and legal operations teams, preparing for these requirements means moving beyond isolated policies and assessments. Organizations need practical AI compliance operations that connect AI inventory, risk management, documentation, governance workflows, and ongoing monitoring.

Companies that approach this as an operational capability, not simply a legal requirement, will be better positioned to achieve EU AI Act readiness while continuing to innovate.

Why AI Governance for HR Has Become a Business Priority

Recruitment AI can influence decisions that directly affect people's careers and livelihoods.

A resume-ranking system may determine which candidates receive an interview. An automated assessment tool may influence whether someone progresses to the next stage. An AI-powered recommendation engine may shape a recruiter's view of a candidate before a human decision is made.
These consequences make governance particularly important.

The EU AI Act recognizes the potential impact of AI in employment. Certain systems used for recruitment, candidate selection, worker management, and related employment decisions can fall within the high-risk category.

For organizations using these technologies, compliance cannot sit exclusively with the legal department.

HR needs to understand how AI is being used. Product teams need to understand governance requirements. IT and security teams need visibility into AI systems. Compliance teams need evidence. Leadership needs confidence that AI adoption is not creating unmanaged regulatory or reputational risk.

This is why AI governance for HR needs to become a cross-functional capability.

The Operational Challenges Behind Recruitment AI Compliance

Knowing that recruitment AI needs governance is relatively straightforward. Implementing it across a growing organization is considerably harder.

Many companies adopt AI tools through different teams, vendors, and business units. Some systems may be introduced directly by HR, while others are embedded within existing SaaS platforms.

This creates several practical challenges.

Fragmented AI Inventories

A company may use AI in its applicant tracking system, interview platform, candidate assessment software, talent analytics platform, and internal HR applications.

If these systems are not recorded centrally, the organization may not have a complete picture of its AI footprint.

A useful AI inventory should capture:

AI system and vendor
Business owner
Recruitment use case
Data processed
Risk classification
Deployment status
Applicable policies
Supporting documentation
Monitoring activities

Without this visibility, compliance teams cannot reliably identify which systems require the greatest attention.

Disconnected Documentation

AI governance information frequently exists in multiple places. Risk assessments may be stored in spreadsheets, vendor documentation in procurement systems, technical information with engineering, and HR policies in internal knowledge bases.

This fragmentation becomes a problem when an organization needs to demonstrate compliance.

For applicable high-risk AI systems, organizations may also need technical documentation aligned with Annex IV requirements. Building that evidence retrospectively can be slow, expensive, and error-prone.

Unclear Human Oversight

Many organizations assume that a recruiter reviewing an AI recommendation automatically provides sufficient human oversight.

Effective oversight requires more structure.

Recruiters should understand what an AI system is doing, recognize its limitations, and have the ability to challenge or override outputs when appropriate.

Organizations should also be able to demonstrate how oversight works through defined responsibilities, approval processes, escalation paths, and evidence.

Limited Continuous Monitoring

AI governance does not end when an AI system is approved for deployment.
Models can change. Vendors can update systems. Data can evolve. Performance can deteriorate. New risks can emerge.

A recruitment AI system that appeared acceptable during its initial assessment may require additional review later.

This makes continuous monitoring an important part of sustainable AI compliance operations.

AI Risk Management for Recruitment Systems

AI risk management provides the foundation for responsible recruitment AI.
Rather than treating compliance as a checklist completed before deployment, organizations should establish a lifecycle approach.

Identify AI Risks

Start by understanding how each AI system is used and what decisions it can influence.
Potential risks may involve:

Candidate discrimination
Biased recommendations
Inaccurate predictions
Insufficient transparency
Data quality
Privacy
Security
Lack of human oversight
Vendor dependency
Inadequate documentation

Assess Risk and Implement Controls

Not every AI system creates the same level of exposure. Organizations should evaluate potential impact based on the use case, affected individuals, decision-making influence, and applicable regulatory classification.

Once risks are identified, organizations need documented controls. These may include human review procedures, testing and validation, data governance, bias monitoring, vendor assessments, approval workflows, and incident management.

Monitor Throughout the AI Lifecycle

Risk assessments should not become static documents.
Organizations should review AI systems when:

A model changes
A vendor updates its technology
A new recruitment use case is introduced
Performance changes
An incident occurs
Regulations or internal policies change

This lifecycle approach strengthens EU AI Act readiness.

Transparency and Human Oversight in AI-Powered Recruitment

Compliance is only one reason transparency matters. Candidates increasingly expect organizations to explain how technology is involved in hiring decisions.

When AI contributes to recruitment, organizations should consider how they communicate:

Where AI is being used
What role it plays in recruitment
What information is being evaluated
When humans review AI-generated outputs
How concerns can be raised where applicable

Human oversight should also be designed directly into the recruitment workflow.

Recruiters should have sufficient context to evaluate AI recommendations and the authority to challenge or override them when appropriate.

Organizations should maintain evidence such as review records, approval history, override decisions, escalation records, training records, and governance approvals.

This evidence can become valuable during audits, procurement reviews, and internal investigations.

Annex IV Documentation Should Become an Operational Process

For applicable high-risk AI systems, documentation is one of the most important areas to manage effectively.

Annex IV documentation should not be treated as paperwork prepared only before a regulatory review. It forms part of the evidence demonstrating how an AI system has been developed, governed, assessed, and monitored.
Depending on the system, documentation may cover:

Intended purpose
System functionality
Risk management
Data governance
Human oversight
Performance
Testing and validation
Monitoring
System changes
Applicable controls

The challenge is keeping this information current.

A governance process that depends entirely on manual document collection becomes increasingly difficult as an organization's AI footprint grows.

Building Scalable AI Compliance Operations

The next stage of AI governance is operationalization. Companies need repeatable workflows that make compliance part of normal business operations.

Create a Central AI Inventory

Know what AI systems exist, where they are deployed, who owns them, and what risks they create.

Establish Clear Ownership

Assign governance responsibilities across HR, compliance, legal, IT, security, and product teams.

Standardize Risk Assessments

A consistent assessment process makes it easier to evaluate new AI systems and prioritize risks.

Centralize Documentation

Keep important evidence accessible instead of scattering it across disconnected tools.

Track Governance Activities

Teams should know what has been reviewed, what remains outstanding, who is responsible, and when the next review is required.

Monitor Continuously

Governance should continue after deployment. Continuous monitoring creates a feedback loop between AI performance, risk, compliance, and business decisions.

Why AI Governance Is Becoming an Enterprise Procurement Requirement

Regulatory compliance is not the only factor driving investment in AI governance.

Enterprise customers are increasingly evaluating the governance maturity of AI vendors before purchasing their products.

Procurement and legal teams may ask vendors for evidence of:

AI risk assessments
Governance policies
Security controls
Data management practices
Human oversight
AI system documentation
Compliance procedures
Monitoring processes

For AI startups and SaaS companies, these requests can directly influence sales cycles.

A company may have a strong AI product, but if it cannot provide credible governance evidence, enterprise buyers may delay procurement or choose a competitor.

This makes AI governance a commercial capability, not just a compliance function.

AI Governance Platform vs. Manual Compliance Management

As AI adoption grows, managing governance through spreadsheets, shared drives, and disconnected documents becomes increasingly difficult.

An AI governance platform can provide a centralized operational layer for managing AI systems, risks, documentation, responsibilities, and compliance activities.

The goal is not to replace legal or compliance expertise. Instead, technology should make governance easier to execute consistently.

A mature platform can help organizations:

Maintain an AI inventory
Track AI risk assessments
Assign governance responsibilities
Manage compliance documentation
Monitor outstanding actions
Organize evidence
Support audit preparation
Maintain visibility across AI systems

How AnnexOps Helps Operationalize AI Compliance

Preparing for the EU AI Act requires more than understanding the regulation. Organizations need an operating model that turns requirements into repeatable actions.

AnnexOps provides operational infrastructure for organizations looking to strengthen their AI governance and compliance processes.

The platform helps teams manage structured governance workflows, centralized documentation, AI risk management, Annex IV documentation, governance tracking, and audit readiness.

This allows organizations to replace disconnected spreadsheets and manual processes with more structured compliance operations.

The objective is not to replace compliance expertise. It is to give HR, legal, compliance, product, and technology teams a shared operational framework for managing AI governance as the organization's AI footprint grows.

A Practical AI Governance Checklist for HR Teams

Before deploying or expanding AI in recruitment, organizations should ask:

Do we have a complete inventory of recruitment AI systems?
Have we identified systems that may qualify as high-risk?
Do we understand how each system influences hiring decisions?
Have we completed appropriate AI risk assessments?
Are human oversight responsibilities clearly defined?
Can recruiters meaningfully challenge AI recommendations?
Are transparency processes documented?
Is required technical documentation maintained?
Can we manage applicable Annex IV documentation effectively?
Are AI systems continuously monitored?
Can we produce compliance evidence quickly?
Are our AI vendors prepared to support compliance requirements?

If several answers are unclear, the organization may have a governance gap, not simply a documentation gap.

Conclusion: Build AI Governance Before You Need It

AI is becoming deeply integrated into recruitment, but organizations that benefit most will be those that can demonstrate control over how their systems operate.

The EU AI Act raises the bar for applicable high-risk AI systems, requiring organizations to think seriously about risk management, transparency, human oversight, documentation, and monitoring.

For HR and recruitment teams, the right response is not another isolated policy. It is an operational governance model.

By building structured AI compliance operations, centralizing documentation, maintaining strong AI risk management practices, and keeping evidence audit-ready, organizations can turn compliance from a reactive burden into a scalable business capability.

The goal is not simply to be prepared when an audit arrives. It is to build an AI governance foundation that remains reliable as the organization deploys more AI, enters new markets, and faces increasingly demanding enterprise customers.

Ready to strengthen your AI governance and EU AI Act readiness?

AnnexOps helps AI-driven organizations manage AI risk, documentation, governance workflows, and audit readiness through structured compliance operations.

👉 Explore AnnexOps and build a scalable foundation for AI compliance.

Learn how AnnexOps helps AI-driven companies prepare for the EU AI Act with clarity and confidence.