AI Vendor Risk in Aerospace Follows the Contract Data

FAR 52.204-21 defines a covered contractor information system by what it does: it handles Federal Contract Information through processing or storage, including while transmitting it. The clause requires controls on external system connections and tells the prime to include the clause's substance in subcontracts where FCI may reside or transit. An aerospace engineer who sends contract data to an external model has created another processing route, even when the prompt leaves through an approved SaaS product. AI vendor risk aerospace programs need to govern that route at the request, because the contract data moves one prompt at a time.

I want to work through the point where supplier diligence ends and model-call authorization begins.

TL;DR

• FAR 52.204-21 follows Federal Contract Information into contractor and relevant subcontractor systems.
• NIST SP 800-171 Rev. 3 applies security requirements to nonfederal systems that handle CUI through processing or storage, including while transmitting it.
• An approved AI provider still needs request policy tied to identity, program, data class and destination, with model version recorded too.
• The defensible record is written before the outbound model call proceeds.

Contract data defines the control boundary

The FAR clause avoids a product list. It defines Federal Contract Information as nonpublic information provided by or generated for the Government under a contract to develop or deliver a product or service, subject to stated exclusions. A covered contractor information system is any contractor-owned or contractor-operated system that handles that information through processing or storage, including while transmitting it.

That wording makes an AI request relevant through function. If a prompt contains an engineering-change explanation generated for a federal program, the system transmitting it has entered the data path. The clause's minimum controls include limiting access to authorized users and permitted functions, verifying external system connections, identifying users and processes acting for them. It also requires identity authentication and protection for communications at external boundaries.

The subcontract paragraph matters for vendor risk. It requires the clause's substance in relevant subcontracts, including many commercial products and services, where a subcontractor may have FCI residing in or transiting through its system. Procurement classification and counsel determine whether a particular AI provider relationship is a subcontract. Security still needs the same technical answer: which contract data reached which external system?

CUI raises the evidence standard

NIST SP 800-171 Revision 3 addresses the confidentiality of Controlled Unclassified Information when it resides in nonfederal systems and organizations. Its control families include access control, audit and accountability, incident response, system and services acquisition, and supply chain risk management.

An aerospace company may hold public technical material, proprietary company information, FCI, CUI, and export-controlled technical data in adjacent repositories. A model request can combine material from more than one class. The gateway decision therefore needs the classification present in the request body, plus the program and contract context supplied by the calling application.

Vendor approval alone is too coarse. A provider may be acceptable for public standards research and prohibited for a prompt containing CUI. Another endpoint may be authorized inside a specific managed environment, but only for named programs and roles. The decision follows the data route, rather than the provider logo.

The regulatory record for aerospace is covered in AI audit trails for aerospace. Vendor risk adds the proof that a destination was authorized for this class of contract data at this moment.

Program context has to survive the model call

Aerospace access control is usually program-aware before AI enters the picture. Engineers badge into controlled rooms, repositories apply need-to-know groups, and drawings carry classification markings. The model call can strip that context away.

Picture a red program banner across the top of a drawing viewer. The engineer copies four lines of a failure-analysis note into a chat pane beside it. The red banner stays on the left screen. The text on the right leaves as an HTTPS request with a corporate identity and a generic API credential. Without program context on that request, an enforcement point sees an employee and a destination, but misses the contract boundary visible to the human.

The application should attach program and contract attributes, plus role and data class to the outbound request. The enforcement layer then evaluates those attributes with content classification, provider approval and region, with model version included. A mismatch can refuse the request or route it to an internal model approved for that program.

This extends the post-authentication gap into aerospace. A valid identity grants entry to the workflow. Per-request authorization decides whether that identity may send this program's content to this model.

Supplier assurance needs operational proof

An AI vendor review can examine security architecture, personnel access, data handling, incident terms, subprocessor use, model updates, deletion, evidence delivery, and assessment history. Those answers establish the vendor's approved operating conditions. The runtime policy should carry them as machine-readable constraints.

For example, the inventory can mark a provider as approved only in a named region, through a private endpoint, for a defined model family, and for data below a specified classification. A provider assessment expiry can automatically restrict new calls until review. A changed model identifier can require fresh approval instead of inheriting permission from the vendor name.

My opinion is that a supplier scorecard without a model-route policy is a paper control. Aerospace companies already understand configuration control. Letting a provider swap the model behind an unchanged endpoint while the approval remains green would be rejected in almost any other engineering context.

A request record should capture authenticated identity, acting service or agent, program, contract, data classification, provider, model version, region, policy version, decision, reason, region, and timestamp. Write-path independence matters because the application requesting access should not be the sole keeper of evidence about its own request. AI vendor risk management describes the diligence layer; the model boundary turns those findings into enforceable conditions.

DeepInspect

DeepInspect is a stateless proxy on authenticated HTTP calls to LLM endpoints. It receives identity and program context from the aerospace application, classifies request content, checks the destination and model against policy, and can permit or redact the call, route it elsewhere, or refuse it before contract data reaches the provider.

Every decision creates a signed record containing the authenticated caller, acting agent or application, supplied program context, request classification, provider, model version, region, policy version, outcome, reason, region, and timestamp. The record is committed outside the calling application's write path. DeepInspect governs the managed AI route. Contract interpretation and CUI marking remain with the teams responsible for them. Export classification, supplier qualification, repository access, and incident reporting also remain with the teams responsible for them.

Book a demo today.