Dev.to AI 🤖 Ai Thu, 05 Nov 2026 06:32:18 +0000 👁 0 📖 8 min read

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

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 dependenci

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.