Airlines should remove unnecessary sensitive data from the repositories that AI can reach, then enforce retrieval and permission boundaries before deployment. The key control is not model tuning but data minimisation, because AI tools surface whatever their users or service accounts can already access. If the source estate is overexposed, the AI layer magnifies that exposure.
What airlines should remove before AI systems are connected
The first step is to treat the AI connection as an exposure decision, not a model feature decision. Airlines should inventory the repositories, document stores, ticketing exports, operational datasets and support systems that AI can reach, then remove anything the model does not need for the business task. That includes sensitive passenger data, employee data, operational secrets, and broad historical content that is convenient but unnecessary.
Data minimisation works because AI systems do not invent new access, they amplify existing access. If the underlying estate is already broad, the AI layer can surface data that users, prompts or service accounts were never meant to see together. A useful baseline is to classify what must remain available for the use case, and treat everything else as out of scope by default.
For practitioners building a data-cleanup programme, the most practical lens is whether each dataset would still be acceptable if it were searched and summarised at scale. NHIMG’s Data Security Guide is useful here because it frames exposure reduction around data discovery, over-permissioned data and securing data for AI, which is the real control problem before any model is deployed.
How permission boundaries should be set before deployment
After minimisation, put hard retrieval limits around the data the AI can query. The important question is not whether the model is clever, but whether retrieval is constrained to the smallest set of sources needed for the workflow. Separate human access from AI access, and separate general search or summarisation use cases from write or action privileges.
That boundary should be enforced at the data layer, the retrieval layer and the identity layer. In practice, this means limiting which indexes, buckets, tables, files or APIs are exposed to the AI, and ensuring the AI is operating through a dedicated service identity with narrowly scoped permissions rather than inheriting broad user entitlements. If the AI can query everything, prompt discipline will not save you.
Airlines should also assume that over-broad retrieval becomes an audit and incident problem later. The Top 10 Data Security Risks guide is a good companion because it ties overexposed data and weak access governance to the conditions that make AI exposure worse, not better. For a deployment programme, AI Security Posture Management is also relevant because it focuses on AI asset discovery, misconfiguration and workload identity, which are the control points that decide what the AI can actually reach.
What to do when data minimisation is not enough
Some airline use cases will still need access to customer records, booking history, disruption data or internal operations content. When that happens, reduce exposure through scoped retrieval, redaction, retention limits and environment separation rather than by allowing broad corpora into the AI stack. If the use case needs only recent records, do not expose entire archives. If a field is not needed for the answer, mask it before retrieval or indexing.
Retention matters because AI systems can make old exposure live again. Long-lived repositories, stale exports and duplicated datasets are common sources of accidental reach, especially when multiple teams have built separate data marts over time. Deleting stale content and keeping retention policies aligned to the actual use case reduces the chance that the AI becomes a discovery path to material that should already have been retired.
That is why the control should be applied before deployment rather than after users start testing prompts. The Data Retention and Secure Deletion Guide is directly relevant because it treats retention boundaries and secure deletion as part of reducing the data surface available to AI. If the airline wants a stronger operational reference point, the Generative AI Data Loss Prevention Guide covers prompt redaction, browser controls and RAG oversharing, which are the common failure modes when data boundaries are too loose.
Risk and Threat Considerations
When airlines connect AI systems to internal data estates, the main risk is not only accidental exposure, but broad secondary exposure through search, summarisation and retrieval. A tool that can answer questions across multiple systems can also stitch together fragments that were never intended to be reviewed together, especially if service accounts inherit broad read access.
Failure mechanism: Overexposed source data, broad retrieval scopes and weak permission boundaries allow the AI layer to surface data that exceeds the intended audience, and any compromise of the AI path inherits the same reach.
Impact: Sensitive passenger, employee, operational or commercial data can be disclosed at scale, and the blast radius is determined by the estate’s existing permissions, not by the model itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | AI retrieval limits depend on who and what can access source data. |
| Recommendation — Scope AI access through IAM so retrieval uses narrowly granted identities and permissions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The answer centers on reducing AI reach to only necessary data sources. |
| IA-9 — Service Identification and Authentication | AI systems often reach data through service identities and automated access paths. | |
| SI-12 — Information Management and Retention | Minimising exposed data requires retaining only what the AI use case truly needs. | |
| Recommendation — Apply least privilege to AI service accounts and retrieval paths. Authenticate AI services explicitly before allowing access to repositories and APIs. Limit retained data and remove stale records before exposing them to AI. | ||
| CIS Controls v8 | 5 — Account Management | AI exposure is controlled by the accounts and service identities that can query data. |
| Recommendation — Review and restrict accounts that can reach AI-connected data stores. | ||
Practitioner Guidance
What to verify: Before connecting an AI system, verify the exact data sources it can query, the identities it uses, and whether each source is necessary for the use case. If a repository is not needed for the workflow, exclude it rather than trying to rely on downstream prompt controls.
Decision rule: If the AI can reach data that would be unacceptable for a human analyst with the same task, the exposure model is too broad and the deployment should be redesigned. If the use case can be served with a narrower dataset, remove the rest first and only then test retrieval quality.
Practitioner takeaway: The safest AI deployment is usually the one that has less data to see, fewer places to search and a narrower identity boundary than the business initially requested.
Related resources from NHI Mgmt Group
- How should security teams reduce data exposure before connecting enterprise data to AI tools and agents?
- How should financial institutions anchor agentic AI workflows in trusted identity before connecting them to credit data and onboarding systems?
- How should security teams secure agentic AI before connecting it to enterprise systems and data?
- How can organisations reduce data exposure in AI tools?