AI Vendor Risk for Airlines Lives at the Operational Interface

Commission Implementing Regulation (EU) 2023/203 treats aviation as an interconnected system of systems and requires information-security risk management across organizational interfaces. Part-IS also requires contracted information-security activities to remain compliant and under oversight. An airline that connects an operations assistant to an external model creates exactly that kind of interface: authenticated operational context leaves one organization and enters another provider's processing environment. AI vendor risk airlines programs need to record and govern each crossing, because an annual vendor review cannot reconstruct Tuesday's dispatch request.

I want to trace that interface from the airline identity to the model endpoint and show where useful evidence gets written.

TL;DR

• Part-IS requires organizations to identify interfaces with other organizations that can create mutual information-security exposure.
• Contracted information-security activities stay under organizational oversight, with associated risks appropriately managed.
• NIS2 Article 21 includes direct suppliers and service providers in required supply-chain security measures.
• Airline AI policy needs per-request identity, operational context, destination and model version, plus the outcome.

Part-IS starts with the interface

The recitals to Regulation 2023/203 explain why generic information-security programs fall short for aviation. The requirements cover aviation domains and their interfaces because the sector is a tightly connected system. Part-IS then turns that premise into risk-assessment work.

IS.I.OR.205 requires an organization to identify its activities and facilities, as well as resources and received or maintained services that may face information-security risk. It also requires identification of interfaces with other organizations where mutual exposure can arise. Risks with a potential impact on aviation safety must be assigned a level and tied back to the affected element or interface.

An external AI endpoint is an interface in the plain technical sense. The airline sends data, receives generated output, depends on provider behavior, and may embed that output in an operational workflow. The relevant risk varies by request. Public passenger guidance has one profile. A prompt carrying a maintenance discrepancy narrative, crew detail, or a dispatch procedure carries another.

The useful inventory therefore contains both the approved vendor relationship and the live routes through which airline systems call it.

NIS2 adds the direct supplier relationship

NIS2 Article 21 requires risk-management measures that are technically, operationally, and organizationally appropriate and proportionate. Paragraph 2(d) expressly includes supply-chain security and the security-related aspects of relationships with direct suppliers or service providers.

The directive's recital 85 names data storage and processing providers, managed services, software editors, and security services as examples of supply-chain relationships that can expose an entity through third-party vulnerabilities. Airlines within the directive's scope therefore have a second reason to connect procurement evidence with actual service use.

A supplier register can show that a provider passed review. It rarely proves which model version handled an operational request, which employee or agent initiated it, which airline system supplied the context, or which policy allowed the transfer. Those fields belong to the transaction record.

The broader record design appears in AI audit trails for airlines. Vendor risk adds the approved operating conditions and the evidence that each call stayed inside them.

Operational context changes the same vendor call

Airline teams can use the same provider for low-risk drafting and safety-adjacent work. A destination allowlist treats both calls alike. The request body and workflow context reveal the difference.

Picture an operations desk before first departure. A printed load sheet sits under a keyboard, the gate clock reads 05:42, and an agent asks a model to summarize a delay note. A second request from the same browser includes crew names and the aircraft registration, along with maintenance text copied from another screen. The hostname and user are unchanged. Provider approval is unchanged too. The operational risk is different.

The application should attach the airline function, station and flight or tail context where appropriate, plus caller identity and the acting service to the request. Content classification adds categories such as passenger data, crew data, maintenance information, public material, or security-sensitive operational detail. Policy then decides whether the selected provider and model are approved for that combination.

A request can proceed, proceed after redaction, route to an internal endpoint, or stop. The AI policy enforcement at the HTTP layer is where that decision can happen before the provider receives the payload.

Oversight becomes measurable at request time

Part-IS provisions on contracting require the organization to keep contracted activities compliant and under oversight while managing the associated risks. For airline AI use, oversight should produce evidence with enough resolution to test the control.

The provider inventory can hold approved regions, authorized model families, permitted data classes, incident contacts and assessment dates, plus contract restrictions and change-notice terms. The request policy reads those attributes alongside identity and content. A model change can move calls into review. An assessment expiry can limit use. A request carrying a protected category can select an internal route.

My view is that airline supplier governance should treat model versions like operational configuration items. Allowing an opaque version change under an unchanged vendor name creates a control exception that would look absurd in a maintenance system.

Each decision record should carry the authenticated caller, acting application or agent, airline function, relevant operational identifier, request classification, provider, model version, region, policy version, outcome, reason, region, and timestamp. A separate write path keeps the evidence available if the calling workflow fails. AI vendor risk management supplies the diligence structure; per-request evidence makes oversight testable.

DeepInspect

DeepInspect provides a stateless proxy for authenticated HTTP traffic between airline users or agents and LLM endpoints. It receives identity and operational context from the calling system, classifies the request, checks provider and model attributes, and can permit or redact the call, route it elsewhere, or refuse it before the payload reaches the vendor.

Each decision writes a signed record with caller identity, acting service, supplied flight or station context, request classification, provider, model version, region, policy version, outcome, reason, region, and timestamp. The record commits outside the calling workflow. DeepInspect governs the managed model-call interface. Part-IS scoping, safety assessment, supplier approval and occurrence reporting stay with the airline. Operational decisions also stay with the airline and its competent authority relationships.

Book a demo today.