AI Audit Trail for Airlines: Part-IS Records When Operations Uses a Model

Point IS.I.OR.245 of Commission Implementing Regulation (EU) 2023/203 requires an aviation organisation to retain information security incident records for five years. Point IS.I.OR.220 requires measures to detect incidents and vulnerabilities. Put those two together and a question falls out that most airline security teams have not yet answered: when a crew planner pastes a roster extract containing licence numbers into a commercial chat product, which system notices, and what does it write down? The regulation has applied since 22 February 2026. An ai audit trail airlines can actually produce needs to close that gap at the request itself.

I want to walk through the Part-IS points that AI usage touches, why the existing detection stack stays silent on this traffic, and what a five-year record has to contain to still be useful in year four.

TL;DR

• Part-IS has applied since 22 February 2026, and its detection duty under IS.I.OR.220 covers information security events regardless of whether a model was involved.
• IS.I.OR.230 sets an external reporting deadline not exceeding 72 hours from the time the condition has been known, so the discovery moment governs the clock.
• IS.I.OR.245 requires five years of incident record retention, which rules out logging systems that roll off at 90 days.
• The record that satisfies all of this names the authenticated person, the destination model and the data class, and it gets written before the response comes back.

What Part-IS asks an organisation to detect

Point IS.I.OR.200 obliges the organisation to run an information security management system that identifies risks, applies treatment measures and detects events. Point IS.I.OR.205 asks it to identify the elements exposed to information security risk and classify them by severity.

Aviation organisations have worked through that exercise for flight planning systems, maintenance records and the operational control network. Model traffic tends to be absent from the inventory, partly because it arrived through individual employee behaviour rather than through a procurement decision. Design and production organisations along with aerodrome operators reached the same duties earlier, under Commission Delegated Regulation (EU) 2022/1645, which has applied since 16 October 2025.

The exposure sits in ordinary work. A maintenance controller asks a model to summarise a defect history. A dispatcher checks a weather interpretation. An operations analyst pastes a delay report to get a draft explanation. Each request may carry registration numbers, crew identifiers or commercially sensitive schedule data out of the organisation, and the network sees a TLS session to a well-known domain.

The reporting clock and the discovery problem

Point IS.I.OR.215 requires an internal reporting scheme to enable the collection and evaluation of information security events. Point IS.I.OR.230 then sets the external obligation, with notification as soon as the condition has been known and a report not exceeding 72 hours from that point.

Seventy-two hours is generous if you know. Discovery is the constraint. An intrusion leaves artifacts behind it, while a prompt leaves nothing but a helpful answer. The employee who sent it has no reason to file an internal report, because from their seat nothing went wrong.

A detection capability that works on this traffic changes the internal reporting scheme from something that depends on self-disclosure into something that depends on a record. That shift is, in my view, the single most valuable thing a Part-IS programme can do about AI this year, and it is considerably less glamorous than the tabletop exercises that tend to get the budget.

Five years is a design constraint

Most security event pipelines in this sector retain hot data for weeks and warm data for a few months. IS.I.OR.245 asks for five years on incident records.

That horizon changes what you should write per event. A five-year-old record has to be legible to someone who was not there, so it needs to carry the interpretation alongside the raw values. Per request, the useful content covers the timestamp, the authenticated person resolved through the organisation identity provider, that person's role and operational function, the calling application or agent, the destination provider with model name and version, the classification applied to the request content, the policy version in force at that moment, the outcome, and a hash of request and response.

The policy version matters more than teams expect. In year four, an auditor asking why a request was allowed will not accept the current ruleset as an answer. The record has to point at the rule that existed on the day.

Storage has to stay independent of the application that made the request, and retrieval has to run by person, by aircraft registration, by time range or by model version. Those are the axes an investigation actually uses. A general text search across five years of log lines does not qualify.

Agents in operational workflows

Airlines are wiring models into disruption management, turnaround prediction and crew communication drafting. Those flows run as services on shared credentials.

An agent request authenticated with a service account satisfies the network and defeats the investigation. The record shows a workflow fired. It cannot show which duty officer's decision triggered it, so the Part-IS event evaluation under IS.I.OR.215 has nothing human to attach to. Carrying the initiating person's identity through to the model request, and recording both the person and the agent, keeps the evaluation possible. The broader pattern appears in agentic AI audit trail, and the cross-regulation view sits in audit trail requirements by regulation.

Point IS.I.OR.260 closes the loop with periodic assessment and corrective action. Corrective action on a class of events you cannot count amounts to a policy memo, which is why the counting has to come first.

DeepInspect

DeepInspect sits between authenticated users or agents and any LLM endpoint as a stateless proxy. Identity resolution, classification of request content, model routing and policy enforcement happen inline on the HTTP request, which gives IS.I.OR.220 detection something to detect and gives IS.I.OR.215 an event to evaluate.

Every decision writes a signed record carrying the authenticated person, the role and operational function, the classification applied, the destination model and version, the policy version in force, the outcome and the timestamp. Records commit to append-only storage before the response returns to the caller, retention configures past the five-year Part-IS floor, and retrieval by person, time range, model version or free identifier runs in seconds. The boundary covers authenticated HTTP traffic between your people or agents and the models they call. ISMS ownership, the safety risk assessment, the incident classification decision and the competent authority relationship stay with the people who hold them now.

If your Part-IS evidence for model usage currently rests on employees remembering to file an internal report, the request-level record is what closes it. Book a demo today.